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Introduction 


The  Information  System  Laboratory  (Institut  fur  Informationstechnische  Systeme,  IIS)  of 
the  Department  of  Computer  Science,  University  of  the  Federal  Armed  Forces  Munich, 
Germany  offered  its  students  a  new  lap  of  the  sequence  of  seminars  on  ’Mobile  Systems’, 
this  time  during  the  winter  term  2004  (WT04). 

Even  today,  the  increasing  number  of  mobile  and  wireless  networks  as  well  as  their  users 
or  customers  drive  many  developments  of  systems  and  protocols  for  mobile  systems.  The 
areas  of  underlying  networking  and  development  technology,  of  services  assisting  security 
or  Quality-of-Service  (QoS),  and  of  mobility  support  determine  an  important  part  of  future 
wireless  networks.  Therefore,  this  year’s  seminar  addressed  such  areas  in  more  depth.  The 
understanding  and  clear  identication  of  problems  in  technical  and  organizational  terms 
have  been  prepared  and  challenges  as  well  as  weaknesses  of  existing  approaches  have 
been  addressed  in  a  mobile  and  wireless  environment.  All  talks  in  this  seminar  provide  a 
systematic  approach  to  judge  dedicated  pieces  of  systems  or  proposals  and  their  suitability. 


Content 


This  third  edition  of  this  seminar  -  entitled  ’Mobile  Systems  III’  -  discusses  in  the  first  sec¬ 
tion  ’War  Driving’.  While  the  search  for  open,  unsecured,  and  publicly  available  Wireless 
Local  Area  Networks  (WLAN)  occurred  to  be  a  ’sports  event’,  today  a  well  established 
group  of  people  keep  track  of  those  activities.  This  talk  outlines  the  range  of  actions,  goals 
of  these  activities,  and  the  environment  in  which  these  people  operate. 

The  second  section  addresses  the  area  of  secure  networking  across  public  networks.  In 
particular  it  lists  and  discusses  known  Virtual  Private  Networks  (VPN)  as  well  as  IPSec. 
Their  comparison  and  use  in  wired  and  wireless  networking  domains  conclude  this  section. 

The  third  section  is  driven  by  demands  of  real-time  applications,  which  require  a  real¬ 
time  networking  infrastructure.  Therefore,  the  key  aspects  of  real-time  support  of  wired 
and  wireless  networking  devices  are  discussed  and  major  mechanisms  in  support  of  those 
demands  are  compared. 

Due  to  the  existence  of  wireless  networks  the  support  of  mobility  has  changed  tremen¬ 
dously  the  usage  of  services  of  today’s  Internet  users.  Therefore,  the  fourth  section  focuses 
in  more  detail  on  this  area,  in  particular  on  micro-mobility  support  in  IP-based  networks 
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as  well  as  Mobile  IP  extensions  in  terms  of  hand-off  optimization  and  paging.  A  quite 
extensive  comparison  of  existing  protocols  concludes  this  section. 

The  fifth  section  deals  with  QoS  issues  in  the  WLAN  environment  and  outlines  respective 
standards  available  in  LANs.  This  includes  a  discussion  of  IEEE  802. Ip  and  IEEE  802. IQ 
as  well  as  a  definition  of  QoS  and  one  possible  metering  framework  for  QoS,  the  Real-Time 
Flow  Measurement  (RTFM)  work. 

Driven  by  possible  solutions  and  key  security  concerns  in  mobile  networks,  section  six 
develops  a  view  on  advanced  concepts  for  security  in  those  ones.  The  standard  IEEE 
802.  Hi  addresses  wireless  security  mechanisms,  which  are  analyzed  and  advantages  as 
well  as  drawbacks  are  discussed.  Protocol-independent  security  measures  are  included  in 
this  section  as  well. 

Due  to  the  current  security'  debate,  section  seven  deals  with  intrusion  detection  systems, 
in  particular  addressing  mobile  environments.  Key  functionality  is  described  and  methods 
applied  are  discussed,  while  a  view  on  wireless  systems  is  being  made. 

Finally,  section  eight  presents  an  overview  on  software  environments  for  mobile  devices. 
The  key  role  plays  the  Operating  System  (OS),  and  major  requirements  in  a  mobile 
environment  are  discussed.  Existing  OS  are  presented  and  evaluated.  Finally,  J2ME  is 
outlined  as  a  programming  environment  for  mobile  systems. 


Seminar  Operation 


As* usual  and  well  established  now,  all  interested  students  worked  on  an  initially  offered 
set  of  papers  and  book  chapters,  relating  to  the  topic  titles  as  presented  in  the  Table 
of  Content  below.  They  prepared  a  written  essay  as  a  clearly  focussed  presentation,  an 
evaluation,  and  a  summary  of  those  topics.  Each  of  these  essays  is  included  in  this  technical 
report  as  a  separate  section  and  allows  for  an  overview  on  important  areas  of  concern, 
sometimes  business  models  in  operation,  and  problems  encountered.  In  addition,  every 
student  prepared  a  slide  presentation  of  approximately  45  minutes  to  present  his  findings 
and  summaries  to  the  audience  of  students  attending  the  seminar  and  other  interested 
students,  research  assistants,  and  professors.  Following  a  general  question  and  answer 
phase,  a  student-lead  discussion  debated  open  issues  and  critical  statements  with  the 
audience. 

Local  IIS  support  for  preparing  talks,  reports,  and  their  preparation  by  students  had 
been  granted  Frank  Eyermann,  Peter  Racz,  Arnd  Heursch,  and  Burkhard  Stiller.  A  larger 
number  of  pre-presentation  discussions  have  provided  valuable  insights  in  the  emerging 
and  moving  field  of  Mobile  Systems,  both  for  students  and  supervisors.  Many  thanks  to 
all  people  contributing  to  the  success  of  this  event,  which  has  happened  again  in  a  small 
group  of  highly  motivated  and  technically  qualified  students  and  people. 
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Kapitel  1 

War  Driving  -  An  Approach  to 
Locate  Open  WLANs 


Dirk  Schindler 


Im  Zeitalter  von  Information  und  Kommunikation  gilt  es  die  richtige  Information,  in 
geeigneter  Form,  zur  richtigen  Zeit  am  richtigen  Ort  verfugbar  zu  haben.  Daraus  ergeben 
sich  filr  Untemehmen  u.a.  folgende  Chancen,  die  zur  Steigerung  der  Produktivitat  fuhren 
konnen:  Gesteigerte  Beratungsqualitat,  hoherwertige  Entscheidungsgrundlagen,  effiziente- 
*  re  Prozessablaufe  und  kiirzere  Entscheidungszeitrdume. 

Zusatzlich  erfahren  wir  auch  im  privaten  Bereich  eine  gesteigerte  Lebensqualitat.  Diese 
aufiert  sich  beispielsweise  in  neuen  Kontaktmoglichkeiten  zu  unseren  Mitmenschen  (durch 
SMS,  Email),  ortsunabhangiger  Verfugbarkeit  von  Daten  (z.  B.  Nachrichten,  Telefonnum- 
mem,  Sportergebnisse) ,  sowie  in  der  Annahme  von  verbesserten  Dienstleistungen.  Aktuell 
bieten  mobile,  drahtlose  Kommunikationsgerate  neue  Moglichkeiten  den  bestehenden  In- 
formationsbedarf  zu  decken.  Das  Verhaltnis  von  Kosten  zu  Nutzen  verandert  sich  dabei 
zusehends  zu  Gunsten  der  Anwender  dieser  Technologie.  Diese  Tatsache  in  Verbindung 
mit  einer  Vielfalt  an  sich  bietenden  Einsatzmoglichkeiten  sorgen  fur  schnelle  Verbreitung 
derartiger  mobiler  Kommunikations-  und  Informationssysteme.  Die  Ausbreitung  neuer 
Technologien  birgt  jedoch  zumeist  auch  neue  Risiken.  Die  vorliegende  Seminararbeit  be- 
schreibt  eines  der  Risiken,  welches  beim  Einsatz  von  drahtloser  Netzwerktechnologie  zum 
Tragen  kommt:  Die  unberechtigte  Nutzung  und  das  Ausspionieren  von  Funknetzen. 

Zugleich  erleichtert  diese  Seminararbeit  den  Einstieg  in  die  Thematik  WLAN  (Wireless 
Local  Area  Network). 

Die  Aktualitat  des  Themas  ,)War  Driving “  spiegelt  sich  u.  a.  in  der  Geschwindigkeit  wieder 
mit  der  sich  z.  Zt.  bestehende  Internetforen  in  diesem  Bereich  entwickeln.  Wahrend  der 
dreimonatigen  Ausarbeitungszeit  dieses  Themas  stieg  die  Anzahl  der  Beitrage  im  Deut- 
schen  War  Driving  Forum  um  ca.  300%. 
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1.1  Einleitung 

Sowohl  in  geschaftlichen  als  auch  in  privaten  Bereichen  sind  Lokal  Area  Netzwerke  (LAN) 
heute  weit  verbreitet.  Wahrend  das  Vorhandensein  kabelgebundener  Vernetzung  mittler- 
weile  weitgehend  als  selbstverstandlich  angenommen  wird,  riickt  derzeit  ein  neuer  Trend 
in  den  Mittelpunkt  allgemeinen  Interesses; 

WLAN  (Wireless  Local  Area  Network) 

Die  aktuell  geschaffenen  technischen  Voraussetzungen  versprechen  flexiblen  Netzzugang, 
steigende  Ubertragungsraten  und  langere  Nutzungszeiten  aufgrund  sparsamen  Energie- 
verbrauches.  Umgesetzt  werden  die  Technologien  in  Handys,  Personal  Digital  Assistants 
(PDAs),  Handhelds  oder  Notebooks  und  Laptops.  Aufgrund  der  breitbandigen  Anbindung 
sowie  allgegenwartiger  Netzzugangsmoglichkeit  („ubiquity  of  access11)  erwachsen  viel  ver- 
sprechende  Anwendungsmoglichkeiten.  Wie  schon  mehrfach  innerhalb  der  IT-Branche  be- 
obachtet,  vollziehen  sich  Evolutionsschritte  gelegentlich  in  Form  eines  Hype  (z.  B.  UMTS 
Hype,  XML  Hype,  E-Business  Hype).  Kennzeichnend  dafiir  sind  anfanglich  hohe  z.  T. 
unrealistische  Erwartungen  in  eine  neuartige  Technologie,  die  anschlieBend  in  einen  In- 
teressenabfall  und  letztendlicher  Konsolidierung  in  realistische  Umsetzungsmoglichkeiten 
miinden.  Die  Entwicklung  von  WLAN  Systemen  hat  mittlerweile  die  Phase  der  Konso¬ 
lidierung  erreicht  [1].  Ein  grofier  Markt  an  WLAN  Produkten  existiert  bereits  und  der 
Kampf  urn  Marktfiihrerschaft  und  Nischenplatzierung  ist  in  vollem  Gange.  Jedoch  birgt 
jede  neue  Technologie  auch  neue  Gefahren  in  sich.  Diese  Seminararbeit  soli  dazu  beitragen 
Chancen  und  Risiken  im  Bereich  WLAN  zu  identifizieren  und  besser  abwagen  zu  konnen. 


1.1.1  Vorgehensweise 

Absicht  der  vorliegenden  Arbeit  zum  Thema  „War  Driving  -  An  Approach  to  Locate  Open 
WLANs11  ist  es,  Technologie  und  Ideologie  dieses  neuartigen  Betatigungsfeldes  darzulegen. 
Auf  der  Grundlage  von  Standards  nach  IEEE1  soil  im  Kapitel  1.1.2  ein  Uberblick  fiber  ak- 
tuelle  Entwicklungen  im  WLAN-Bereich  vermittelt  werden.  Im  darauf  folgenden  Abschnitt 
wird  die  Frage  geklart:  „Was  ist  War  Driving?11  Ausgehend  von  dieser  Tatigkeitsbeschrei- 
bung  werden  anschlieBend  im  Kapitel  1.1.4  alle  erforderlichen  Ausrustungsgegenstande 
und  der  Anforderungen  an  diese  beschrieben.  Der  Umgang  mit  den  genannten  Ausriis- 
tungsgegenstanden  wird  in  Kapitel  1.1.5  dargestellt.  Dadurch  soil  ein  Eindruck  aus  der 
Praxis  von  War  Drivern  vermittelt  werden.  Neben  den  Darstellungen  aus  der  „Alltags- 
tatigkeit11  von  War  Drivern  wird  in  diesem  Kapitel  auch  Sicherheitsaspekten  sowie  der 
rechtlichen  Betrachtungsweise  nachgegangen,  um  den  Einblick  in  die  War  Driving  Szene 
zu  komplettieren. 


1In  der  Kommunikations-  und  Datenbanktechnik  existieren  verschiedene  Normierungsgremien.  Ein 
wichtiges  Gremium,  welches  neben  dem  OSI  (Open  Systems  Interconnection)  steht,  ist  das  IEEE  (Institute 
of  Elektrical  and  Electronic  Engineers)  [2]  mit  Sitz  in  New  York.  Dieses  Institut  befasst  sich  mit  der 
Standardisierung  von  elektronischen  Systemen  in  verschiedenen  Gebieten  [3]. 


10 


War  Driving  -  An  Approach  to  Locate  Open  WLANs 


1.1.2  Orientierung 

Diese  Arbeit  stellt  die  Tatigkeit  einer  Gruppe  von  Gleichgesinnten  dar,  deren  Ziel  es  ist, 
mittels  ausgefeilter  Technik  und  zum  Teil  anspruchsvoller  Hard-  und  Software  Zugang 
zu  drahtlosen  Netzwerken  zu  erhalten.  Eine  Bewertung  dieser  Handlungsweise  ist  nicht 
Absicht  der  Arbeit.  Vielmehr  soli  dem  Leser  durch  Aufklarung  iiber  die  aktuellen  techni- 
schen  Moglichkeiten,  die  Vorgehensweisen  innerhalb  der  War  Driving  Communities,  sowie 
anhand  der  Darstellung  der  gesetzlichen  Hintergriinde  eine  eigene  Urteilsbildung  ermbg- 
licht  werden.  Im  Fokus  stehen  dabei  theoretische,  technische  und  gesetzliche  Grundlagen 
die  Einfluss  auf  Ubertragungsraten,  Reichweiten  und  Frequenzauswahl  haben,  da  diese 
Faktoren  fur  den  War  Driver  von  mafigeblicher  Bedeutung  sind.  Aufbauend  auf  diesen 
Grundlagenkenntnissen  erfolgen  Beschreibungen  zum  Aufbau  und  Einsatz  von  Hard-  und 
Software  fur  War  Driver.  Die  dargestellten  Einflussfaktoren  und  Grundprinzipien  liefern 
die  Rahmenbedinungen  fiir  erfolgreiches  oder  nicht  erfolgreiches  War  Driving. 


1.2  Wireless  LAN 


Im  Folgenden  Abschnitt  werden  Funktion,  Aufbau  und  Standardisierungsdetails  von  Wi¬ 
reless  LANs  beschrieben.  Ziel  ist  es,  ein  Grundverstandnis  fiir  die  technischen  Vorausset- 
zungen  zu  vermitteln.  Diese  Voraussetzungen  bilden  die  Basis  des  Umfeldes  in  dem  sich 
alle  War  Driving  Tatigkeiten  bewegen. 


l.JJ.l  Aufbau-  und  Funktionsiiberblick 

Der  Aufbau  bzw.  Ausbau  eines  WLANs  (vgl.  Abbildung  1.1)  ist  bequemer  als  der  Aufbau 
bzw.  Ausbau  eines  LANs: 


Iiitriuet 


Abbildung  1.1:  WLAN  Architektur  (Infrastructure-Modus)  [5] 
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„Anstatt  zum  Beispiel  in  einem  Firmengebaude  in  die  Wande  Locher  fur  die 
Kabel  zu  bohren,  reicht  es,  eine  zentrale  Funkstation,  Access  Point,  an  das 
Strom-  und  lokale  Netz  anzuschliefien,  in  den  Rechner  die  Funknetzkarte  ein- 
zubauen  und  die  Software  zu  installieren.  Dieser  Access  Point  iibemimmt  dann 
die  Versorgung  mit  der  drahtlosen  Netzanbindung  und  dient  als  eine  Ethemet- 
Briicke.“  [4] 


Wahrend  ein  Access  Point  (AP)  den  Nutzer  (client)  immer  mit  genau  einem  Netzwerk 
verbindet,  eignen  sich  WLAN  Router  zur  Anbindung  der  Nutzer  an  mehrere  Netze.  Dabei 
ubernimmt  der  Router  die  IP-Adresse  des  clients  in  seine  Routingtabelle,  wahrend  der 
AP  samtliche  IP-Adressen  ignoriert  und  alle  Datenpakete  weiterleitet  [6] . 


Solange  sich  ein  WLAN  Nutzer  in  Empfangsreichweite  zum  Access  Point  aufhalt  kann 
Datentransfer  in  beiden  Richtungen  zwischen  WLAN  Nutzer  und  LAN  stattfinden.  Im 
Bezug  auf  die  Empfangsreichweite  ist  folgendes  zu  beachten: 


Die  Ausbreitung  von  Funkwellen  hangt  neben  der  Sendeleistung  von  verschiedenen  ortli- 
chen  Gegebenheiten  ab,  die  Einfluss  auf  Absorption,  Reflexion  und  Biindelung  der  Funk¬ 
wellen  haben.  Fur  diese  Arbeit  besteht  Relevanz  nur  insofern,  als  dass  festgestellt  werden 
kann,  dass  die  Ausbreitung  der  Funkwellen  eines  APs  oder  eines  WLAN  Routers  nicht  auf 
die  geographische  Grenze  eines  Gebaudes  oder  eines  Grundstiickes  begrenzt  ist.  Folglich 
ist  der  Netzzugang  zu  einem  WLAN  schwieriger  zu  kontrollieren  als  zu  einem  kabelgebun- 
denen  LAN. 


Neben  dem  in  Abbildung  1.1  dargestellten  „ Infrastructure  Modus11  existiert  noch  eine 
zweite  Architekturform,  der  „Ad  Hoc  Modus11.  Sie  wird  an  dieser  Stelle  der  Vollstandig- 
keit  halber  erwahnt.  Eine  Darstellung  dieses  Modus  liefert  die  Abbildung  1.2. 


Abbildung  1.2:  WLAN  Architektur  (Ad  Hoc  Modus)  [7] 

Fur  die  weitere  Betrachtung  im  Rahmen  dieser  Seminararbeit  ist  letztgenannte  Archi¬ 
tektur  nicht  von  Bedeutung,  da  War  Driver  auf  der  Suche  nach  wieder  auffindbaren, 
stationaren  APs  sind.  Aufgrund  der  Mobilitat  von  Ad  Hoc  Netzen  ist  eine  Auswertung 
und  Informationsweitergabe  liber  aufgefundene  WLAN-Architekturen  dieser  Art  nicht 
sinnvoll. 


12 


War  Driving  -  An  Approach  to  Locate  Open  WLANs 


1.2.2  Der  Standard  IEEE  802.11 

Um  den  Weg  fiir  die  Entwicklung  und  Herstellung  der  ersten  WLAN-Gerate  zu  ebnen 
begann  das  IEEE  Ende  der  90er  Jahre  mit  der  Ausarbeitung  eines  Standards  nach  dem 
WLAN-Gerate  zu  konstruieren  seien,  um  Kompatibilitat  und  Mindestfunktionsumfang 
sicherzustellen.  Mittlerweile  existiert  unter  der  Bezeichnung  IEEE  802.11...  eine  ganze 
Familie  an  Standards.  Eine  Ubersicht  zu  alien  Standards  nach  IEEE  802.11...  ist  in  der 
Tabelle  1.1  dargestellt. 

Tabelle  1.1:  Ubersicht  zu  den  Standards  nach  IEEE  802.11...  [8]: 


IEEE- 

Beschreibung 

802.11 

Protokoll  und  Ubertragungsverfahren  fiir  drahtlose  Netze, 
1997  fiir  2  Mbit/s  bei  2,4  GHz  definiert 

802.11a 

54-Mbit/s-WLAN  im  5-GHz-Band,  12  nicht-iiberlappende 
Kanale,  Modulation:  Orthogonal  Frequency  Division  Multi¬ 
plexing  (OFDM) 

802.11b 

1 1-Mbit /s- WLAN  im  2,4-GHz-Band,  3  nicht-iiberlappende 
Kanale 

802.11c 

Wireless  Bridging  zwischen  AccessPoints 

„W°rld  Mode“,  Anpassung  an  regionsspezifische  Regulatorien 
(z.  B.  Frequenzbereich) 

802. lie 

QoS-  und  Streaming-Erweiterung  fiir  802.11a/g/h  (Priorisie- 
rung  von  Datenpaketen,  z.  B.  fiir  Multimedia- Anwendungen, 
Streaming) 

802. Ilf 

Roaming  fiir  802.11a/g/h  (Inter  Access  Point  Protocol  IAPP), 
bezogen  auf  AccessPoints  verschiedener  Hersteller 

802.  llg 

54-Mbit/s-WLAN  im  2,4-GHz-Band,  Modulation  OFDM 

802. llh 

54-Mbit/s-WLAN  im  5-GHz-Band  mit  DFS2  und  TPC3 

802.  lli 

Verbesserung  von  Authentifizierung/Verschltisselung  fiir 
802.11a/b/g/h  (AES,  802. lx)  Erganzend/Aufbauend  auf 
WEP4  u.  WPA5  (Interimslosung) 

802.11j 

Japanische  Variante  von  802.11a  fiir  den  Bereich  4.9  GHz  - 
5  GHz 

802.11k 

Bessere  Messung/Auswertung/Verwaltung  der  Funkparame- 
ter  (z.B.  Signal-starke),  soli  z.  B.  Ortsbezogene  Dienste 
(location-based  services)  ermoglichen 

802. lima 

Zusammenfassung  friiherer  Erganzungen,  Bereinigung  von 
Fehlern  aus  vorausgegangenen  Spezifikationen  (Maintenance) 

802. lln 

Geplante  Erweiterung  fiir  zukiinftiges,  schnelleres  WLAN  mit 
mindestens  100  Mbit/s 

2Dynamic  Frequency  Selection 
3Transmit  Power  Control 
4Wired  Equivalency  Privacy 

5WiFi  Protected  Access  (WiFi  =  „wireless  Fidelity11:  Standard,  um  Kompatibilitat  zwischen  „wireless“- 
Geraten  unterschiedlicher  Hersteller  zu  gewahrleisten.) 
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Im  Folgenden  Abschnitt  liegt  der  Fokus  auf  den  Standards,  die  fur  das  War  Driving  in 
Deutschland  relevant  sind.  Diese  werden  ausfuhrlich  beschrieben.  Zunachst  sind  ihre  wich- 
tigsten  Eigenschaften  in  einer  tabellarischen  Ubersicht  (Tabelle  1.2)  dargestellt: 


Tabelle  1.2:  Ubersicht  zu  relevanten  WLAN-Standards  im  Hinblick  auf  War  Driving 

■  (Quellen:  [9],  [10]  und  [11]): 


WLAN-Standards  im  Uberblick 

Standards: 

IEEE  802.11a 

IEEE  802. llh 

IEEE  802.11b 

IEEE  802.11g 

Bandbreite: 

54  Mbit/s 

54  Mbit/s 

11  Mbit/s 

54  Mbit/s 

Frequenz: 

5-GHz-Band 

2,4-GHz-Band 

2,4-GHz-Band 

Reichweite: 

12  m  -  20  m 

12  m  -  20  m 

30  m  -  300  m 

20  m  -  100  m 

Besonderes: 

weniger 
Storungen, 
hochste  Kosten 

TPC6,  DFS7 
(Europaische 
Variante  von 
IEEE  802.11a) 

Etabliert, 
niedrigste  Kosten 

Kompatibel  zu 
IEEE  802.11b, 
Kosten: 

„IEEE  802.11b“+10% 

IEEE  802.11  Der  Standard  IEEE  802.11  wurde  Ende  des  Jahres  1999  als  Norm  fur 
Wireless  LANs  verabschiedet  [12].  Die  Spezifikation  beschreibt  die  drahtlose  Schnittstelle 
„over-the-air  interface “  zwischen  dem  client  und  der  Basisstation  bzw.  zwischen  dem 
client  und  dem  AP. 


„Dieser  Standard  war  der  allererste  drahtlose  WLAN-Standard  vom  IEEE.  Er 
ermoglichte  die  Produktion  von  Produkten  mit  einer  Bruttoiibertragungsrate 
von  1  Mbit/s.  Er  f and  in  dieser  Form  keine  grofie  Nutzergruppe.“  [13] 


Der  Standard  IEEE  802.11  legt  neben  den  Verfahren  zur  Authentisierung,  nach  Identify- 
based-  oder  Challenge-Response- Methode,  noch  den  Aufbau  des  WEP-Protokolls  (Wired 
Equivalency  Privacy)  sowie  das  WEP-Verschliisselungsverfahren  fest.  Der  WEP  Schliissel 
wurde  vor  ca.  2  Jahren  gebrochen  und  ist  deshalb  in  dieser  Form  unsicher  [4]. 

IEEE  802.11a  Dieser  Standard  setzt  auf  nutzbare  Frequenzbereiche  im  5-GHz-Band. 
Die  vorhandenen  12  Kanale  sind  nicht  iiberlappend.  Die  Frequenzzuweisung  fur  Europa 
ist  folgendermafien  festgelegt:  Die  Bander  5,15  bis  5,35  GHz  und  5,47  bis  5,725  GHz 
stehen  zur  Verfugung.  Uber  eine  groBere  Anzahl  an  Subcarriern  (als  bei  IEEE  802.11b) 
und  OFDM-Modulation8  wird  eine  Bruttodatenrate  von  maximal  54  Mbit/s  erreicht.  Al- 
le  Gerate  nach  diesem  Standard  miissen  Ubertragungsraten  von  6,  12  und  24  Mbit/s 
unterstiitzen.  Optional  sind  9,  18  und  36  Mbit/s.  Aufgrund  der  Moglichkeit  des  Mehr- 
fachzugriffes  durch  aktive  Nutzer  eines  WLANs  entsteht  auf  der  Ebene  3  (dem  Network 
Layer)  des  OSI-Schichtenmodells  zusatzlicher  Verwaltungsaufwand.  Dieser  sorgt  dafiir, 

6Transmit  Power  Control 

7Dynamic  Frequency  Selection 

8  Orthogonal  Frequency  Division  Multiplexing 
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dass  im  giinstigsten  Falle  von  54  Mbit/s  noch  rund  32  Mbit/s  zur  Verftigung  stehen  [13]. 
Weiterhin  sinkt  der  Nettodatendurchsatz  mit  steigendem  Abstand  zwischen  Sender  und 
Empfanger.  Typischerweise  verringert  sich  der  Datendurchsatz  in  etwa  um  300  Kbit/s 
pro  Meter.  Generell  erreichen  Sender  dieses  Standards  eine  Reichweite  von  30  m  bis  50  m. 
Die  Reichweitenangaben  differieren  in  den  verschiedenen  Literaturquellen,  vermutlich  auf- 
grund  unterschiedlicher  Messverfahren  (sie  liegen  zwischen  12  m  [10]  und  50  m  [13]). 

Fur  den  Einsatzbereich  War  Driving  bedeutet  dies,  dass  aufgrund  der  angegebenen  Reich¬ 
weite,  ein  geographisch  ortsnaher  Zugang  zum  AP  erforderlich  ist.  Eine  Moglichkeit  das 
Reichweitenproblem  zu  verringern,  besteht  in  dem  Einsatz  einer  ausgefeilten  Antenne  oder 
Antennenanlage  (vgl.  Kapitel  1.4.1). 


IEEE  802.11b  Seit  2001  dominieren  auf  dem  Markt  WLAN-Gerate  nach  dem  Stan¬ 
dard  IEEE  802.11b.  Genutzt  wird  hier  das  2,4-GHz-ISM9-Frequenzband.  In  Deutschland 
sind  13  Kanale  zur  Nutzung  freigegeben,  von  denen  drei  jeweils  nicht  iiberlappend  an- 
geordnet  sind.  Erreicht  wird  eine  Dateniibertragungsrate  von  11  Mbit/s.  Aufgrund  der 
relativ  schmalen  Bandbreite  und  zusatzlicher  Nutzung  des  2,4-GHz-ISM-Frequenzbandes 
von  Bluetooth-  oder  Mierowellengeraten  sind  gegenseitige  Beeintrachtigungen  zu  erwar- 
ten  [13].  Die  Funkwellen  dieses  Frequenzbandes  erfahren  aufgrund  der,  im  Vergleich  zum 
5-GHz-Band,  niedrigeren  Sendefrequenzen  eine  geringere  Dampfung.  Die  mogliche  Reich¬ 
weite  liegt  daher  jenseits  der  Reichweite  von  IEEE  802.11a-Geraten  zwischen  30  m  und 
300  m  [10]. 

Besonders  stark  verbreitet  sind  Gerate  nach  IEEE  802.11b  in  den  USA  [9].  Jedoch  auch 
in  Europa  greifen  WLAN  Nutzer  und  damit  ebenfalls  War  Driver  auf  Gerate  dieses  Stan¬ 
dards  zuriick. 

Als  Konsequenz  fur  den  War  Driver  ergibt  sich  bei  der  Verwendung  dieser  Gerate,  auf¬ 
grund  des  Reichweitenvorteils  haufiger  die  Moglichkeit  APs  aufzuspiiren,  als  mit  einer 
Ausriistung  nach  IEEE  802.11a.  Zwar  ist  eine  geringere  Dateniibertragungsrate  hinzu- 
nehmen,  jedoch  sorgt  der  Kostenvorteil  der  IEEE  802.11b-Gerate  fiir  Akzeptanz  und  Ver- 
breitung  innerhalb  der  War  Driving  Communities. 


IEEE  802. llg  Um  der  Forderung  nach  mehr  Bandbreite  sowie  Abwartskompatibili- 
tat  zum  Standard  IEEE  802.11b  nachzukommen,  wurde  im  Juli  2003  IEEE  802. llg  verab- 
schiedet  [14].  Als  obligatorisches  Modulationsverfahren  wurde  OFDM  aus  IEEE  802.11a 
iibernommen.  Die  Vertraglichkeit  aller  Betriebsmodi  zu  IEEE  802.11b  ist  sichergestellt. 
Uber  den  Standard  IEEE  802. llg  wird  eine  Dateniibertragungsrate  von  22  Mbit/s  bis 
54  Mbit/s  ermoglicht.  Die  Reichweite  im  2,4-GHz-Band  liegt  zwischen  30  m  und  50  m. 
Der  Standard  stellt  das  Ende  der  Entwicklung  in  diesem  Frequenzband  dar.  Es  ist  denkbar 
dass  aufgrund  der  starken  Nutzung  dieses  Frequenzbereiches  und  der  damit  verbundenen 
Storanfalligkeit  in  naher  Zukunft  auf  das  storungsfreiere  5-GHz-Band  ausgewichen  wird. 
Auch  steht  im  5-GHz-Band  mehr  Bandbreite  zur  Verfiigung  [13]. 

Fiir  den  Bereich  War  Driving  in  Deutschland  zahlen  Gerate  die  der  Norm  IEEE  802. llg 
entsprechen  vorerst  zur  meist  genutzten  Hardware. 


9ISM  Industrial  Scientific  Medical:  Lizenzfreies  Frequenzband  in  dem  sich  Bluetooth-,  IEEE  802. 11-, 
IEEE  802.11b-  und  Mikrowellengerate  bewegen. 
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IEEE  802. llh  Bei  diesem  Standard  handelt  es  sich  um  eine  Erweiterung  des  IEEE 

802.11a.  Der  Standard  IEEE  802. llh  ist  abwartskompatibel  zu  IEEE  802.11a.  Ein  Gross- 
teil  der  Erweiterungen  betrifft  die  interne  Betriebssoftware.  Ebenfalls  im  5-GHz-Band 
bietet  IEEE  802. llh  eine  Ubertragungsrate  von  bis  zu  54  Mbit/s  bei  gleicher  Reichweite 
wie  IEEE  802.11a.  Mittels  Implementierung  von  DFS  und  TPC  stellt  dieser  Standard 
eine  Art  Endpunkt  der  WLAN-Verfahren  in  diesem  Frequenzband  dar.  An  Leistungsfa- 
higkeit  und  Flexibility  bedeuten  die  beiden  Standards  IEEE  802. llg  und  IEEE  802. llh 
das  Nonplusultra  im  jeweiligen  Frequenzband.  Dieser  Standard  liegt  bisher  in  Form  eines 
Entwurfes  (draft)  vor.  Mit  der  Ratifizierung  und  anschliefiender  Verfugbarkeit  erster  Pro- 
dukte  wird  im  Laufe  des  Jahres  2004  gerechnet  [13]. 

Der  Markt  bietet  derzeit  viele  Gerate  nach  IEEE  802.11a,  IEEE  802.11b  und  IEEE  802. llg 
Standard.  Beide  letztgenannten  sind  unter  War  Drivern  weit  verbreitet.  Inwieweit  sich  Ge¬ 
rate  nach  IEEE  802. llh  im  War  Driving  Bereich  durchsetzten  werden  bleibt  abzuwarten. 
Ebenso  wie  nach  IEEE  802.11a  wird  der  bestehende  Reichweitennachteil  moglicherweise 
durch  geringere  Stdrungsanfalligkeit  ausgeglichen.  Letztendlich  werden  sehr  wahrschein- 
lich  die  Kosten,  insbesondere  im  Vergleich  zu  Geraten  nach  IEEE  802. llg,  fiber  die  zu 
erreichenden  Marktanteile  entscheiden. 


IEEE  802. Hi  Hier  handelt  es  sich  um  eine  Erweiterung  der  Standards  IEEE  802.11a, 
IEEE  802.11b  sowie  IEEE  802. llg,  um  bekannte  Sicherheitsliicken  des  WEP  zu  schliefien. 
Beabsichtigt  ist  die  Einfiihrung  eines  neuen  Protokolls.  Mit  Implementierung  des  Tempo¬ 
ral  Key  Integrity  Protocol  (TKIP)  kommen  rotierende  Schliissel  zum  Einsatz,  die  jeweils 
nach  kurzer  Lebensdauer  durch  neue  ersetzt  werden.  Der  Standard  existiert  derzeit  als 
draft  und  soil  in  Kiirze  ratifiziert  werden  [12],  [15]. 

Fur  War  Driver  wird  die  Umsetzung  des  Standards  eine  neue  Herausforderung  darstel- 
len.  Galt  die  Aktivierung  von  WEP  bisher  nicht  mehr  als  nennenswertes  Hindernis  beim 
Versuch  Zugang  zum  AP  zu  erhalten,  so  verspricht  IEEE  802. lli  auch  WEP2002  genannt 
vorerst  hochgradige  Sicherheit  aufgrund  der  Verfahren10  Re-Keying,  Per-Packet-Mixing, 
Re-Sequencing  und  Message-Integrity-Check  (MIC). 

1.2.3  Aktuelle  Entwicklung  im  Bereich  WLAN 

Derzeit  nimmt  die  Verbreitung  von  WLANs  trotz  Sicherheitsbedenken  zu.  Es  besteht  bei 
vielen  Unternehmen  ein  reges  Interesse  an  drahtlosen  Netzen.  Durch  den  Einsatz  draht- 
loser  Technologie  soli  die  Mobilitat  der  Mitarbeiter  und  damit  auch  die  Produktivitat 
gesteigert  werden.  Da  die  Systeme  einfach  zu  installieren  sind  und  heute  in  aller  Regel 
per  Plug  and  Play  in  Betrieb  genommen  werden  konnen  besteht  eine  entsprechend  grofie 
Nachfrage  [16].  Nach  Schatzung  der  Gartner-Group  soil  es  23  Millionen  WLAN-Nutzer 
bis  zum  Jahre  2007  geben  [17]. 

Weiterhin  existiert  die  Forderung  nach  grofierer  Bandbreite,  ahnlich  der  100  Mbit/s  in 
LANs.  Dazu  wurde  durch  das  IEEE  im  September  2003  die  Arbeitsgruppe  IEEE  802. lln 
eingerichtet.  Ziel  ist  die  Erreichung  einer  Dateniibertragungsrate  in  WLANs  von  100  Mbit/s 
effektiv.  Mogliche  Techniken  konnen  sein  Channel  Bonding,  Antennenarray  (MIMO11). 

10Die  Darstellung  der  genannten  Verfahren  ist  u.a.  in  [10]  S.  280  f.  zu  finden. 

11  Models  and  Infrastructures  for  Mobile  Computing 
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Dadurch  sollen  zukiinftig  neue  Anwendungen  insbesondere  im  Bereich  Multimedia  mog- 
lich  werden.  Die  Fertigstellung  des  Standards  wird  fiir  Oktober  2005  erwartet  [18].  (Zwi- 
schenzeitliche  Meldungen,  dass  der  Standard  friiher  verabschiedet  werden  wiirde  sind  de- 
mentiert.) 

An  einer  anderen  Entwicklung  arbeitet  derzeit  das  Europaische  Institut  fiir  Telekommuni- 
kations-Standards  (ETSI)  [12].  Die  Arbeit  an  einem  Standard  unter  dem  Namen  Hiper- 
LAN/212  hat  an  dieser  Stelle  jedoch  lediglich  informativen  Charakter.  Fiir  das  War  Driving 
besteht  keine  Relevanz,  da  es  keinerlei  Produkte  nach  diesem  Standard  gibt  und  die  Zu- 
kunft  dieses  Standards  ungewiss  ist.  Integrierte  Schnittstellen  zum  Mobilfunk  der  dritten 
Generation  (G3  oder  UMTS)  sowie  zum  High-Speed-Bus  (IEEE1394)  postulieren  fiir  die 
Zukunft  ein  „integratives  Netzwerk“  [13]  unter  dem  unterschiedlichste  Dienste  zusammen- 
gefasst  werden  konnen.  Auch  hier  geht  der  Trend  in  Richtung  zunehmender  Mobilisierung, 
bei  grofier  Bandbreite  und  steigenden  Ubertragungsgeschwindigkeiten  unter  Erfiillung  be- 
stehender  Qualitatsanforderungen . 


1.3  „War  Driving44  -  Begriffsklarung/Hintergriinde 

Fiir  den  ersten  Teil  des  Begriffes  kristallisiert  sich  in  Insiderkreisen  die  Bedeutung  Wire¬ 
less  Access  Revolution  (WAR)  heraus.  Der  letztere  Teil  des  zweiteiligen  Begriffes  „Driving“ 
bezeichnet  das  Umherfahren  in  Automobilen.  Die  Ausiibung  von  War  Driving  kann  je¬ 
doch  auch  zu  Fufi  erfolgen  und  auch  das  War  Cycling  (Radfahren)  wird  erwahnt.  Aus 
verschiedenen  Definitionen,  die  im  Internet  zu  finden  sind,  hier  zwei  der  treffendsten: 

«  War  Driving:  „Die  Suche  nach  drahtlosen  Netzwerken  durch  Einwahl  ( auf  dem 
Fuftweg  oder  wahrend  des  Fahrens  (in  Pkw  oder  Bus))  mittels  drahtlosem  Ein- 
wahlgerdt.  Gelegentlich  unterstutzt  durch  Verwendung  von  hochverstarkenden 
Antennen  und  GPS-Gerdten  (Global  Positioning  System). “  [19] 


War  Driving:  „Das  Umherfahren  (im  Pkw)  bei  gleichzeitiger  Suche  nach  unge- 
schutzten  drahtlosen  Netzwerken  -  Begriffspragung  durch  Peter  Shipley.  “  [19] 


1.3.1  Entstehung  des  War  Driving 

Peter  Shipley  beschaftigte  sich  um  die  Jahrtausendwende  intensiv  mit.  der  Sicherheit 
von  Netzwerken.  Zunachst  war  sein  Blickpunkt  ausgericht.et  auf  die  Sicherheit  von  Netz- 
werkverbindungen  fiber  kabelgebundene  Modems.  Eine  seiner  Veroffentlichungen  befasst 
sich  mit  der  „ Analyse  von  Einwahlmodems  und  deren  Sicherheitsliicken"  [20].  Ausgangs- 
punkt  war  der  Hollywood  Film  „War  Games“  (1983).  Der  Film  lieferte  breiten  Anlass  fiir 
Computer-  und  Netzwerkinteressierte  zu  Erproben,  inwieweit  sie  durch  Wahlen  zufalliger 
Telefonnummern  Zugang  zu  ungesicherten  Netzen  erhalten  konnten.  Damals  wurde  der 
Begriff  „War  Dialing"  gepragt  [21]. 


12High  Performance  Radio  Local  Area  Network,  Type  2 
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Eine  parallele  Entwicklung  vollzog  sich  aufgrund  der  erweiterten  Bandbreite  die  mit  der 
Einfiihrung  von  LANs  (Local  Area  Network)  geschaffen  wurde.  Der  Versuch  eigene  un- 
genutzte  Bandbreite'  fiir  andere  zuganglich  und  nutzbar  zu  machen  (vgl.  Kapitel  1.3.3), 
fand  schnell  Ubertragung  in  den  WLAN-Bereich.  Anfanglich  wurden  offentlich  zugangli- 
che  APs  mit  Tafelkreide  auf  Biirgersteigen  oder  an  Hausfassaden  markiert  (Warchalking) 
[22].  Spater  gingen  Menschen  auf  die  Suche  nach  bisher  unveroffentlichten  Zugangsknoten. 
Mafigeblich  beteiligt  an  der  Pragung  des  Begriffes  „War  Driving11  war  Peter  Shipley  [19]. 
Zwar  fuhren  andere  vor  Ihm  durch  Stadt  und  Land  auf  der  Suche  nach  ungeschutzten 
kabellosen  Zugangsknoten  (wireless  access  point  (AP)).  Jedoch  war  Peter  Shipley  der 
erste,  der  die  Suche  und  Sammlung  von  Informationen  uber  Zugangsknoten  komplett  au- 
tomatisierte.  Die  Automatisierung  erfolgte  unter  Zuhilfenahme  eines  GPS-Gerates  und 
ausgewahlter  Software  (vgl.  Kapitel  1.4.2). 


1.3.2  Idee  und  Absicht 


Es  stellt  sich  die  Frage:  Aus  welchem  Grund  investiert  jemand  Zeit,  Geld  und  Arbeit  in 
eine  Tatigkeit,  fur  die  die  Aussichten  auf  Dank  oder  Entlohnung  als  gering  anzusehen 
sind? 

Im  Rahmen  der  Arbeit  an  diesem  Thema  fanden  sich  keinerlei  empirische  Untersuchun- 
gen/Untersuchungsergebnisse,  die  gesicherte  Erkenntnisse  uber  die  Intentionen  der  War 
Driver  liefern  konnten.  Den  Internetforen  ist  zu  entnehmen,  dass  die  Motivation  zum  War 
Driving  sehr  differ enziert  sein  kann: 

Sie  mag  von  wissenschaftlichem  Interesse  in  Bezug  auf  Ausbreitung  und  Nutzung  der 
WLAN-Technologie  und/oder  dem  praktischen  Testen  von  Sicherheitsmechanismen,  uber 
den  Wunsch  nach  kostenlosem  Netzzugang,  oder  dem  Reiz  des  Neuen,  Elitaren,  Halblega- 
len  bis  hin  zu  dem  Drang  sich  unberechtigt  Daten  und  Informationen  zu  verschaffen  (mit 
destruktivem  Charakter)  gehen. 

Letzteres  gehort  eindeutig  nicht  zu  den  Intentionen  der  War  Driver  Gemeinschaft  (com¬ 
munity).  Erkenntlich  wird  das  daran,  dass  auf  alien  Internetseiten  zu  War  Driving  sowie 
auf  alien  Veroffentlichungen  zu  War  Driving  folgender  Hinweis  zu  finden  ist: 


„Reminder.  Don’t  break  the  LAW  while  wardriving,  this  will  only  give  us  ne¬ 
gative  feedback  and  will  hurt  everyone  in  wardriving  community.  “  [19] 


Die  Art  der  Veroffentlichungen  lasst  darauf  schliefien,  dass  der  eigentliche  Zweck  des  War 
Driving  die  Sammlung  von  Informationen  ist.  Diese  werden  aufaggregiert  und  in  Form  von 
Kartenmaterial  (vgl.  Kapitel  1.5.1)  oder  Tabellen  veroffentlicht.  Auf  diese  Weise  wird  auf 
Sicherheitsliicken  hingewiesen  und  zur  Sensibilisierung  wenig  sicherheitsbewusster  WLAN- 
Nutzer  beigetragen.  Aufierdem  werden  gewonnene  Erfahrungen  und  Informationen  im 
Rahmen  von  War  Driving  Treffen  ausgetauscht  und  erganzt. 


18 


War  Driving  -  An  Approach  to  Locate  Open  WLANs 


1.3.3  Interessengemeinschaften  und  Vereinigungen 

Interessengruppen  bilden  sich  z.  Zt.  vielerorts  iiber  das  Internet.  Wahrend  sich  in  den 
USA  bereits  in  vielen  Stadten  WAR  Driving  Gemeinschaften  (communities)  formiert  ha- 
ben,  gibt  es  Bundesweit  erst  eine  einzige.  Auf  der  Internetseite  „Deutsches  Wardriving- 
Portal“  [23]  wird  die  Anzahl  der  registrierten  Benutzer  mit  iiber  1.000  angegeben  (Stand: 
Jan.  2004).  Aktuell  formieren  sich  War  Driving  Communities  in  den  grofien  Stadten  wie 
Berlin,  Diisseldorf,  Frankfurt,  Hamburg,  Miinchen  und  weiterer. 

Auch  in  anderen  Landern  Europas  entstehen  Internetportale  und  Foren  zum  Thema  War 
Driving  (vgl.  Tabelle  1.3  im  Anhang  A).  Die  Internetseite  „www.Mobileaccess.de“  [24]  er- 
moglicht  die  Suche  nach  vorhandenen  offentlichen  Hot-Spots  in  Deutschland,  Osterreich 
und  der  Schweiz.  Der  starke  Zuwachs  an  Informationen  sowohl  auf  dieser  Internetseite  als 
auch  in  verschiedenen  War  Driving  Foren  kann  als  Nachweis  dienen,  dass  Interesse  und 
Mitgliederzahlen  im  War  Driver  Umfeld  in  diesen  Monaten  eine  besonders  groBe  Wachs- 
tumsrate  erleben. 

Wahrend  die  Zusammenarbeit  in  Europa  noch  im  Aufbau  ist,  gibt  es  in  den  USA  bereits 
regelmafiige  Treffen  und  intensiven  Informationsaustausch  [25].  Einige  Gruppen  verfolgen 
heute  die  Zielsetzung  ein  ftir  jedermann  frei  zugangliches  WLAN  fiir  den  geographischen 
Bereich  ganzer  Stadte  einzurichten  -  so  genannte  FreeNets  (vgl.  Tabelle  1.4  im  Anhang  B). 
Die  Vorstellung  geht  dahin,  dass  private  Haushalte  ihren  Zugang  zum  AP  offen  lassen. 
So  konnen  andere  clients  diesen  Zugang  nutzen,  wahrend  man  selber,  quasi  im  Gegenzug, 
andere  WLAN-Verbindungen  nutzt/  nutzen  kann  sobald  man  sich  aufier  Haus  begibt. 


1.4  Technische  Ausriistung 


Das  Angebot  an  technisch  geeigneter  Ausriistung  fiir  den  War  Driver  ist  vielfaltig.  Sowohl 
im  Hardwarebereich  als  auch  im  Bereich  der  Software  existiert  bereits  ein  breiter  Markt 
an  Produkten.  Die  Darstellung  einer  umfassenden  Ubersicht  wiirde  den  Rahmen  dieser 
Arbeit  sprengen.  Daher  wird  im  Folgenden  das  Hauptaugenmerk  auf  haufig  genutzte  Hard- 
und  Softwareprodukte  gelegt. 


1.4.1  Benotigte  Hardware 

Grundsatzlich  eignet  sich  jede  mobile  Hardware  mit  der  Zugang  zu  WLAN  (wireless  ac¬ 
cess)  hergestellt  werden  kann.  Im  Rahmen  von  Durchfuhrung/Ausiibung  des  War  Driving 
kommen  Notebooks,  Laptops  oder  PDAs  zum  Einsatz.  Diese  werden  um  ein  Schnittstel- 
lengerat  zum  Funkempfang  (wireless  device),  eine  Antenne  und  ggf.  um  ein  GPS-Gerat 
erganzt  (vgl.  Abbildung  1.3). 

Notebook13/PDA  Um  der  Anforderung  nach  Eignung  fiir  Netzwerktechnologie  ge- 
recht  zu  werden,  sollte  das  Gerat  iiber  eine  CPU  mit  einer  Taktfrequenz  von  400  MHz 
(oder  hoher)  verfiigen.  Die  sinnvolle  GroBe  fiir  den  Arbeitsspeicher  liegt  bei  128  MB  RAM. 


13Notebook  wird  hier  als  Synonym  fiir  Notebooks  und  Laptops  eingesetzt. 
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Sofern  diese  Hardware  die  Ausfiihrung  eines  Betriebssystems  (vgl.  Kapitel  1.4.2)  unter- 
stiitzt  sind  alle  erforderlichen  Voraussetzungen  gegeben  [26]. 


Abbildung  1.3:  War  Driving  System  [19] 

Wireless  Device  Die  derzeit  verfiigbaren  Wireless  LAN  Karten  unterstiitzen  den 
Anschluss  an  eine  von  zwei  moglichen  Schnittstellen.  Es  existieren  PCMCIA-Karten  und 
USB-Karten.  Fiir  beide  Arten  sind  sowohl  Ausfiihrungen  nach  IEEE  802.11a  als  auch 
nach  IEEE  802. llg  erhaltlich.  Ein  Vorteil  der  USB- Ausfiihrung  liegt  in  der  Moglichkeit 
das  Gerat  flexibel  im  Fahrzeuginnenraum  zu  platzieren.  Nicht  alle  Karten  bieten  die  Mog¬ 
lichkeit  zum  Anschluss  einer  Antenne.  Um  War  Driving  Resultate  zu  optimieren  ist  dies 
ein  wichtiges  Kriterium  [23]. 

Antennen  Bilder  und  Diskussionen  aus  bestehenden  Internetforen  machen  deutlich, 
dass  dem  Einfallsreichtum  bei  der  Auswahl  einer  Antenne  kaum  Grenzen  gesetzt  sind. 
Schon  ein  Eigenbau  [27]  ermoglicht  eine  Verstarkung  des  Eingangssignales  um  bis  zu  12 
db.  Dadurch  ergibt  sich  fiir  War  Driver  beim  Aufspiiren  von  Netzen  ein  Antennenvorteil 
mit  einem  Faktor  von  8  [28]. 

Es  kommen  unterschiedliche  Antennentypen  zum  Einsatz  (Beispiele:  Stabantennen,  Draht- 
antennen,  Hohlstabe,  Miniaturantennen).  Generell  lasst  sich  zwar  die  Aussage  vertreten 
„je  grofier  die  Antenne  desto  besser  der  Empfang“  [27].  Jedoch  muss  die  Antenne  im  Pkw 
handhabbar  bzw.  eine  sichere  Montage  gewahrleistet  sein. 

Obwohl  die  Empfangerempfindlichkeit  gesetzlich  nicht  begrenzt  ist,  gilt  auch  fiir  den  Ein¬ 
satz  von  Antennen,  dass  nicht  alles  was  von  War  Drivern  eingesetzt  werden  kann  den 
gesetzlichen  Bestimmungen  entspricht. 

GPS-Einheit  Zur  eigentlichen  Ausiibung  des  War  Driving  wird  ein  GPS-Gerat  nicht 
unmittelbar  benotigt.  Es  erleichtert  jedoch  das  Auffinden  bereits  bekannter  APs  und  ist 
dariiber  hinaus  erforderlich,  um  APs  in  eine  geographische  Kartensoftware  einzutragen. 
(Beispielsweise:  Microsoft  Mappoint  oder  Microsoft  Autoroute  Express  [26].)  Auch  der 
GPS-Markt  bietet  eine  groBe  Varietat  an  Geraten.  Fiir  den  Einsatz  im  Rahmen  von  War 
Driving  Fahrten  sind  keinerlei  besondere  Anforderungen  erforderlich.  Ein  Gerat  welches 
dem  aktuellen  Stand  der  Technik  entspricht  reicht  daher  fiir  War  Driving  Zwecke  aus. 

Spannungsversorgung  Zum  Betrieb  eines  einzelnen  Notebooks  oder  PDAs  ist  die 
Anschaffung  eines  geeigneten  12V-Adapters  ausreichend.  Fiir  den  gleichzeitigen  Betrieb 
mehrerer  Einheiten  im  Rahmen  von  Gruppen  War  Driving  im  gleichen  Fahrzeug,  geht 
aus  den  Internetforen  die  Empfehlung  hervor  einen  Spannungswandler  einzusetzen.  Diese 
liefern  110  bzw.  220  Volt  und  leisten  Unterstiitzung  fiir  maximal  drei  Gerate. 


20 


War  Driving  -  An  Approach  to  Locate  Open  WLANs 


1.4.2  Benotigte  Software 

War  Driving  Software  gibt  es  fiir  nahezu  alle  Betriebssysteme  (z.  B.:  Windows,  Linux, 
Mac-OS,  BSD-OS  (Berkeley  Software  Design-Operating  System),  WinCE,  WinMobile 
2003).  Einschrankungen  bestehen  bei  Win98  und  Friiheren  aufgrund  mangelhafter  Netz- 
werkfunktionalitat.  Die  gesamte  Software  im  Hinblick  auf  das  War  Driving  Tatigkeitsfeld 
umfasst  Anwendungsprogramme  zum  Aufspiiren  von  wireless  APs,  Scannen  und  Uberwa- 
chen  von  Netzwerken  sowie  zur  Erstellung  von  Landkarten.  Treiber  und  Hilfsprogramme 
zur  Anbindung  der  individuellen  Hardware  seien  hier  nur  der  Vollstandigkeit  halber  er- 
wahnt. 

Ermitteln  von  Access-Standorten  Zum  Aufspiiren  von  APs  eignen  sich  Netstum- 
bler  und  ISS  unter  Windows,  Wellenreiter  und  Kismet  unter  Linux  sowie  Kismae  und 
Macstumbler  unter  Macintosh.  Bei  alien  Produkten  handelt  es  sich  um  Freeware.  Auf¬ 
grund  der  steigenden  Nachfrage  an  derartigen  Werkzeugen  und  dem  aktiven  Einsatz  durch 
War  Driver  haben  die  aufgefiihrten  Programme  bereits  einen  qualitatssichernden  Entwick- 
lungsprozess  durchlaufen.  Im  Folgenden  soil  ein  kurzer  Einblick  in  die  Moglichkeiten  und 
Anwendungsweise  derartiger  Software  am  Beispiel  von  Netstumbler  gegeben  werden: 
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Abbildung  1.4:  Netstumbler:  Access  point  found  [23] 


Im  Anwendungsfenster  des  Netstumblerprogrammes  (vgl.  Abbildung  1.4)  wird  jeder  ge- 
fundene  Zugangsknoten  aufgelistet.  Es  werden  u.  a.  Daten  zu  folgenden  Kategorien  ermit- 
telt  und  aufgelistet:  Empfangsanzeige,  MAC-Adresse,  SSID,  Sende-  und  Empfangskanal, 
Hersteller  des  AP  (Erlaubt  Ruckschliisse  auf  Standardpassworter),  Typ  (AP),  Signalst.ar- 
ke,  Verschliisselungsinformationen,  GPS-Daten.  Den  Farben  der  Empfangsanzeige  kommt 
jeweils  folgende  Bedeutung  zu: 


Grim:  Guter  Empfang  Gelb:  Mafiiger  Empfang  Rot:  Kein  ausreichender  Empfang 

Zusatzlich  besteht  die  Moglichkeit  die  eingehende  Signalstarke  anzeigen  zu  lassen.  Die 
Darstellung  erfolgt  im  Programm  in  graphischer  Form  (vgl.  Abbildung  1.5)  und  ermog- 
licht  die  Auswahl  eines  APs  mit  ausreichender  Sendeleistung. 
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Abbildung  1.5:  Netstumbler:  Modus-Sendeleistung  [23] 


Die  generell  einfache  Anwendung  erlaubt  auch  nicht  versierten  Computernutzern  schnelles 
Auffinden  von  APs  und  damit  den  leichten  Einstieg  in  das  War  Driving. 

IDS  oder  Sniffer  Softwareprodukte  dieser  Kategorie  ermoglichen  auf  unterschiedli- 
che  Art  und  Weise  das  Eindringen  in  Netzwerke.  Unter  Umgehung  von  SicherheitsmaB- 
nahmen  konnen  beispielsweise  Netzwerkdaten  ausspioniert  werden.  Daher  ist  diese  Art 
von  Software  als  sicherheitsgefahrdend  einzustufen.  Eine  groBe  Auswahl  an  Programmen 
unterschiedlicher  Funktionalitat  wird  im  Internet  dokumentiert  oder  zum  download  ange- 
boten.  Fertige  Softwarelosungen  existieren  nicht  nur  zur  Ermittlung  des  WEP-Schliissels 
(vgl.  Kapitel  1.2.2  (S.  9),  Kapitel  1.5.2  und  [29]).  Auch  das  komfortable  Abhoren  (vgl. 
Aerosol  (PRG)  [30])  und  Analysieren  von  Datenpaketen  (vgl.  Colasoft  Capsa  (PRG)  [31]) 
und  sogar  das  Vortauschen  eines  AP  mittels  einer  einfachen  WLAN-Netzwerkkarte  ist 
moglich  (vgl.  HostAP  (PRG)  [32]).  Die  aufgefiihrten  Tools  sollen  als  Beispiele  dienen  wel- 
che  Moglichkeiten  sich  dem  War  Driver  bieten  [29],  Diese  kleine  Auswahl  macht  deutlich, 
welche  Chancen  und  Risiken  in  derartiger  Software  liegen.  Chancen  bieten  sich  fur  Ad- 
ministratoren  und  authorisiertem  Personal  zur  Priifung  ihres  Netzes.  Risiken  bestehen  im 
feindlichen  Einsatz  solcher  Werkzeuge. 

Allgemeine  Erganzungen  Nicht  jede  Software  ist  kompatibel  zur  Hardware.  Die 
Internetforen  (vgl.  [23] ,  [25]  und  Anhang  A)  liefern  eine  Fiille  an  Informationen  iiber 
mogliche  erfolgreiche  Systemkonfigurationen.  Zu  vielen  Problemen  bestehen  bereits  Er- 
fahrungswerte  auf  die  angehende  War  Driver  zuriickgreifen  konnen. 

Ein  interessanter  Softwarebereich  aus  War  Driving  Sicht  ist  das  Angebot  an  Kartensoft- 
ware.  Programme  wie  Stumbverter  (Windows)  oder  GPSD  (Linux)  komplettieren  das 
Softwarepaket  eines  War  Drivers.  Mit  ihnen  lassen  sich  punktgenau  geographische  Posi- 
tionen  innerhalb  digitaler  Landkarten  eintragen  und  speichern.  Dazu  werden  iiber  eine 
Schnittstelle  geographische  Positionen  z.  B.  aus  der  Netstumbleranwendung  entnommen 
und  in  vorhandene  digitale  Kartendateien  exportiert  [19]. 

Es  klang  bereits  an,  dass  wahrend  der  Entwicklung  von  Softwareprodukten  im  Bereich 
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drahtloser  Netzwerktechnik  die  rechtlichen  Bestimmungen  der  verschiedenen  Lander,  in 
denen  die  Tools  zum  Einsatz  kommen,  keine  Berticksichtigung  finden.  Leicht  gerat  ein  Nut- 
zer  durch  Installation  und  Anwendung  eines  Freeware  Tools  in  den  Bereich  der  Illegalitat. 
Die  Grenzen  sind  dabei  fliefiend.  Aufgrund  unterschiedlicher  Funktionalitat  innerhalb  der 
Anwendungsprogramme  lasst  sich  eine  klare  Trennung  zwischen  legaler  und  illegaler  Soft¬ 
ware  oft  nicht  treffen. 

Es  hangt  zuletzt  zum  Einen  vom  Verantwortungsbewusstsein  des  Nutzers  und  zum  An- 
deren  von  der  Errichtung  ausreichender  Sicherheitsvorkehrungen  durch  den  Betreiber  ab, 
inwieweit  rechtliche  Bestimmungen  eingehalten  werden. 


1.5  Einsatzbeispiele  von  War  Driving 


In  diesem  Abschnitt  soli  zunachst  ein  Eindruck  aus  der  Praxis  vermittelt  werden.  Anhand 
eines  Kartenausschnitts  wird  aufgezeigt  in  welcher  Art  die  Darstellung  und  Auswertung 
gewonnener  Informationen  nach  einer  War  Driving  Einsatzfahrt  erfolgen  kann.  Im  An¬ 
schluss  folgen  Uberlegungen  zu  Sicherheitsaspekten  und  rechtlichen  Hintergriinden. 


1.5.1  Ergebnisauswert  ung 

Die  Abbildung  1.6  zeigt  das  Ergebnis  einer  War  Driving  Fahrt  vom  14.  Januar  2004  aus 
Lancaster  (USA): 
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Abbildung  1.6:  Resultat  eines  War  Driving  Einsatzes  [19] 
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Wahrend  dieser  Fahrt  wurden  79  APs  ermittelt.  Samtliche  Zugangsdaten  wurden  gespei- 
chert.  Mittels  GPS  wurden  gleichzeitig  die  Symbole  fur  Zugangspunkte  durch  die  Software 
in  den  entsprechenden  Positionen  auf  der  Karte  eingetragen. 

Durch  WEP  geschiitzte  Zugangsknoten  werden  dabei  als  AP-Symbol  in  roter  Farbe  ver- 
merkt  (4k).  Ungeschiitzte  APs  entsprechen  den  griinen  Markierungen  (4). 

Wird  die  selbe  Route  mehrfach  abgefahren,  konnen  verlassliche  Informationen  gewonnen 
werden.  Anhand  der  gespeicherten  Daten  sind  dann  statistische  Aussagen  zu  relevanten 
Fragestellungen  moglich,  wie  z.  B: 

•  Wie  vollzieht  sich  die  Ausbreitung  von  WLAN  Systemen?  • 

•  Wie  schnell  wachst  die  Anzahl  an  WLANs? 

•  Wie  grofi  ist  der  Anteil  an  ungesicherten  APs? 

•  Steigt  der  Anteil  an  gesicherten  APs? 

•  Gibt  es  lokale  Unterschiede  beziiglich  des  Sicherheitsbewusstseins? 

So  lassen  sich  Aussagen  treffen  inwieweit  Aufklarungsarbeit  von  War  Drivern  oder  In- 
formationssendungen  in  TV  und  Rundfunk  das  Verhalten  der  WLAN-Administratoren 
beeinflusst.  Uber  den  Vergleich  bzw.  Austausch  der  Ergebnisse  mit  anderen  War  Dri¬ 
vern  sind  zusatzlich  auch  Aussagen  iiber  die  Qualitat  der  jeweils  genutzten  War  Driving 
Ausrustung  moglich. 


1.5.2  Sicherheitsaspekte 

An  dieser  Stelle  wird  nicht  auf  die  Gefahren  wahrend  der  Ausiibung  von  War  Driving,  die 
sich  vorwiegend  auf  si'cheres  Fiihren  des  Kraftfahrzeuges  beschranken,  eingegangen.  Viel- 
mehr  sollen  sicherheitsrelevante  Aspekte  wahrend  des  Betreibens  von  WLANs  aufgezeigt 
werden  die  sich  z.  T.  aus  den  Inhalten  des  Kapitels  1.2.2  ergeben: 

Bei  der  Einrichtung  von  Hot-Spots14  in  Form  von  Burgernetzen  (Flughafen,  Bahnhofe, 
Cafe,  Messen,  etc.)  ist  zu  beachten,  dass  von  Seiten  der  Klienten  kein  Zugriff  auf  sicher¬ 
heitsrelevante  Daten  moglich  ist.  Daher  sollten  die  APs  keine  direkte  Anbindung  an  das 
lokale  Netzwerk  besitzen,  sondern  zuvor  eine  Firewall  iiberbrucken  rmissen  [9]. 

Ebenso  besteht  fur  den  Einsatz  von  drahtlosen  Firmennetzen  ein,  im  Vergleich  zum  LAN, 
erhohtes  Sicherheitsrisiko.  Aufgrund  der  Eigenschaften  von  Funkwellen  (vgl.  Kapitel  1.2.1) 
ist  die  Zugangskontrolle  mit  erhohtem  softwaretechnischen  Aufwand  verbunden.  Moglich- 
keiten  bieten  1)  die  Aktivierung  von  WEP,  2)  die  Zulassung  oder  Auswahl  bestimmter 
MAC15-Adressen,  3)  Unterbindung  der  Ubertragung  des  Service  Set  Identifiers  (SSID) 
oder  4)  die  Einrichtung  eines  Virtual  Private  Network  (VPN). 

14Geographischer  Ort,  an  dem  drahtloser  breitbandiger  Internetzugang  iiber  einen  Zugangsknoten  (AP) 
zur  Verfugung  gestellt  wird. 

15Media  Access  Control 
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1)  Problematisch  bei  WEP  ist,  dass  der  RC4-Schlfissel  mittels  Brute  Force  Verfahren 
durch  heutige  Softwareprodukte  in  relativ  kurzem  Zeitraum  errechnet  werden  kann.  Ent- 
sprechende  Tools  [16]  (Wepcrack,  Airsnort,  Kassandra)  sind  im  Internet  erhaltlich  und 
fester  Bestandteil  im  Werkzeugkoffer  von  War  Drivern. 

2)  Die  Zugangssicherung  mittels  Angabe  von  MAC-Adressen  erfordert  manuelle  Ver- 
waltungsarbeit,  die  sich  nur  bei  kleineren  Netzen  noch  in  angemessener  Zeit  bewaltigen 
lasst.  Diese  Schutzmafinahme  lasst  sich  durch  MAC-Spoofing16  umgehen.  Auch  hierzu 
wird  per  Internet  in  den  War  Driving  Foren  unterstiitzende  Software  angeboten. 

3)  Ein  Basic  Service  Set  (BSS)  kann  durch  einen  Netzwerknamen,  den  SSID  identi- 
fiziert  werden.  Das  Unterdriicken  der  Ubertragung  des  SSID  ist  per  Default-Einstellung 
zunachst  nicht  aktiviert.  Sobald  es  aktiviert  ist  besteht  ein  gewisser  Schutz  gegen  Ein- 
dringversuche  einiger  WLAN-Scanner.  Jedoch  ermitteln  verschiedene  andere  frei  erhaltli- 
che  Tools  die  SSID  dennoch  anhand  von  Steuer  und  Managementsignalen. 

4)  Grofitmogliche  Sicherheit  bietet  die  Einrichtung  eines  VPN,  welches  zwischen  den 
Clients  und  der  lokalen  Firewall  implementiert  wird.  Zusatzlich  sollten  standige  Kontrol- 
len  durch  ein  Wireless  Intrusion  Detection  System  erfolgen. 

Die  dargelegten  Informationen  zu  moglichen  Sicherheitsmafinahmen  machen  deutlich,  dass 
mit  Ausnahme  von  4)  Errichtung  eines  VPNs,  jede  einzelne  Mafinahme  nur  unzureichen- 
den  Schutz  gegen  Angriffe  auf  WLANs  bietet.  Da  die  Mafinahmen  zu  den  Punkten  1)  bis 
3)  mittlerweile  leicht  zu  umgehen  sind,  bietet  erst  wieder  die  Kombination  mehrerer  Si¬ 
cherheitsmafinahmen  einen  wirkungsvollen  Schutz  gegen  Datenraub  und  -missbrauch.  Da- 
bei  sollte  unternehmensweit  eine  ganzheitliche  Sicherheitspolicy  aufgesetzt  werden.  Fiir 
regelmafiige  „Risk  Assessments11  [9]  bietet  sich  die  Nutzung  eines  Dienstleisters  in  IT- 
Risikofragen  an.  Generell  ist  eine  Aufwand-Nutzenrechnung  zu  erstellen,  auf  deren  Basis 
eine  Abschatzung  fiber  den  Umfang  sinnvoller  Sicherheitsmafinahmen  erfolgen  kann. 

In  vielen  Fallen  werden  aufgrund  von  Unwissenheit  die  verffigbaren  Sicherheitsverfahren 
nicht  eingesetzt.  Die  Tatsache,  dass  in  den  Defaulteinstellungen  zur  Einrichtung  von  wi¬ 
reless  LANs  alle  Sicherheitsmafinahmen  deaktiviert  sind  tragt  nicht  zur  Aufklarung  bzw. 
zur  Steigerung  der  Netzwerksicherheit  bei.  Aber  selbst  wenn  implementierte  Mafinahmen 
eingesetzt  werden,  bieten  sie  haufig  nicht  den  gewunschten  Schutz.  In  der  aktuellen  Situa¬ 
tion  unterstfitzen  Softwaretools  aus  dem  Internet  den  War  Driver  bei  der  Umgehung  der 
meisten  Sicherheitsmafinahmen.  Erst  die  Implementierung  zukfinftiger  neuer  Sicherheits- 
techniken  z.  B.  nach  dem  Standard  IEEE  802. lli  (vgl.  Kapitel  1.2.2)  bietet  im  Bereich 
WLAN  erhohte  Sicherheit. 


1.5.3  Rechtliche  Betrachtungsweise 

Der  §3  des  Telekommunikationsgesetzes  (TKG)  vom  25.  Juli  1996  beinhaltet.  eine  gesetzli- 
che  Begriffsbestimmung  zu  den  Worten  „Betreiben“,  „Endeinrichtungen“,  „Funkanlagen“, 


16Vorspiegelung  einer  gefalschten  MAC-Adresse. 
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„Netzzugang“,  „Nutzer“  und  Weiterer.  Aus  Sicht  des  War  Driving  ist  neben  diesen  Grund- 
lagen  insbesondere  der  §86  Satz  2  TKG  von  Interesse.  Dort  heifit  es: 

„Mit  einer  Funkanlage  diirfen  Nachrichten,  die  fur  die  Funkanlage  nicht  be- 
stimmt  sind,  nicht  abgehdrt  werden.  Der  Inhalt  solcher  Nachrichten  sowie  die 
Tatsache  ihres  Empfangs  diirfen,  auch  wenn  der  Empfang  unbeabsichtigt  ge- 
schieht,  auch  von  Personen,  fur  die  tine  Pflicht  zur  Geheimhaltung  nicht  schon 
nach  §  85  besteht,  anderen  nicht  mitgeteilt  werden.  “ 

Neben  dem  deutschen  Telekommunikationsgesetz  kommen  auch  europaweite  Regelungen 
zum  tragen:  Mit  In-Kraft-Treten  der  „Frequenzentscheidung“17  der  EU  zum  25.  Juli  2003 
gilt  folgende  Regelung: 

„Funk-LAN-Systeme  diirfen  entweder  das  [...]  2,4-GHz-Band18  [...]  oder  die 
[...]  5-GHz-Bander19  [...]  ganz  oder  teilweise20  nutzen.“  [33] 

Bis  dato  war  nicht  klar,  ob  freie  offene  Biirgernetze,  in  Form  grundstticks-iibergreifender 
Funknetze  unter  die  Lizenzpflicht  nach  Paragraph  6  des  Telekommunikationsgesetzes  (TKG) 
fallen.  Diese  Unsicherheit  ist  nun  behoben  und  es  heifit  „freies  Funken“. 

Zusammenfassend  lasst  sich  festhalten:  Das  Senden  und  Empfangen  im  lizenzfreien  Fre- 
quenzspektrum  der  genannten  2,4-GHz-  und  5-GHz-Bander  unterliegt  keinen  Einschran- 
kungen. 

Bezuglich  des  Zugangs  zu  Netzwerken  sieht.  es  ein  wenig  anders  aus.  Sobald  ein  Nutzer  on¬ 
line  geschaltet  ist  werden  Datenpakete  empfangen.  Nach  dem  Auszug  aus  §86  Satz  2  TKG 
diirfen  nur  solche  Daten  empfangen  werden,  die  auch  an  diesen  Nutzer  gerichtet  sind.  Nun 
konnen  War  Driver  durchaus  Daten  aus  dem  Internet  beziehen,  die  fur  sie  bestimmt  sind 
(z.  B.  private  email).  Hier  beschreiten  War  Driver  eine  rechtliche  Grauzone.  Zum  Einen 
mogen  die  Inhalte  durchaus  an  sie  selbst  gerichtet  sein,  zum  Anderen  nutzen  sie  frem- 
de  Netzwerke  und  empfangen  Pakete  von  Sendeanlagen,  die  nicht  fur  ihre  personliche 
Nutzung  in  Betrieb  genommen  wurden.  Es  steht  dabei  aufier  Frage,  dass  die  Anwendung 
einiger  Funktionen  vorhandener  Tools,  die  das  Ausspionieren  von  Netzen,  aufbrechen  von 
Sicherheitsschliisseln,  vorspiegeln  falscher  Tatsachen  (Mac-Spoofing)  ermoglichen,  als  il¬ 
legal  einzustufen  ist.  Diesbeziiglich  wird  in  den  erwahnten  War  Driving  Internetforen' an 
jede  bereitgestellte  Information  oder  Anwendungssoftware  der  Hinweis  gekoppelt  diese, 
im  Sinne  des  Ehrenkodex  (vgl.  Kapitel  1.3.2),  nicht  fur  den  Gesetzesmissbrauch  zu  nut¬ 
zen.  Nach  §95  TKG  droht  demjenigen  Freiheitsstrafe  bis  zu  zwei  Jahren  oder  Geldstrafe, 
der  entgegen  §86  Satz  1  oder  Satz  2  eine  Nachricht  abhort  oder  den  Inhalt  einer  Nach- 
richt  oder  die  Tatsache  ihres  Empfanges  einem  anderen  mitteilt.  An  dieser  Stelle  bleibt  zu 
diskutieren  inwieweit  War  Driving  als  ehrenhafte  positive  Aufklarungsarbeit  anzusehen 
ist,  oder  ob  der  Ehrendcodex  der  War  Driving  Vereinigungen  (vgl.  Kapitel  1.3.2)  mentale 
Rechtfertigung  und  Motivation  liefert,  um  gesetzliche  Grenzen  zu  iiberschreiten. 

17Entscheidung  Nr.  676/2002/EG  des  Europaischen  Parlaments  und  des  Rates  vom  7.  Marz  2002  iiber 
einen  Rechtsrahmen  fur  die  Funkfrequenzpolitik  in  der  Europaischen  Gemeinschaft. 

18Frequenzband  von  2400,0-2483,5  MHz. 

19vgl.  Kapitel  1.2.2 

20Hier  bezieht  sich  ’teilweise’  auf  den  oberen  Bereich  des  5-GHz-Bandes,  der  in  einigen  Landern  fur 
Radar  benutzt  wird. 


26 


War  Driving  -  An  Approach  to  Locate  Open  WLANs 


1.6  Ausblick/Risiken 


Vor  der  Ratifizierung  des  Standards  IEEE  802.  llg  im  Juli  2003  haben  Anbieter  wie  3Com, 
Cisco,  Enterasys  und  Siemens  keine  so  genannten  Vorstandardprodukte  (Pre-g-Produkte) 
auf  den  Markt  gebracht  [9].  Daher  kommen  derzeit  (seit  Abschluss  der  Ratifizierung) 
verstarkt  IEEE  802.11g-Gerate  auf  den  Markt.  Dabei  werden  steigende  Produktionszah- 
len  dieser  Hardware  zu  sinkenden  Preisen  auf  dem  Absatzmarkt  fiihren.  Dariiber  hinaus 
besteht  weiterhin  Nachfrage  an  zusatzlicher  Bandbreite  wie  sie  mittels  IEEE  802. lln  ver- 
wirklicht  werden  soil.  Es  ist  folglich  davon  auszugehen,  dass  sich  aufgrund  der  giinstigeren 
Preise  fur  WLAN-Technik,  der  zunehmenden  Verbreitung  von  WLANs  und  mangelhaftem 
Sicherheitsbewufitsein  vieler  Nutzer  die  Betatigungsmoglichkeiten  fur  War  Driver  auswei- 
ten.  Es  bleibt  zu  hoffen,  dass  die  steigende  Zahl  der  War  Driving-Community-Mitglieder 
sich  an  den  selbst  vorgegebenen  Ehrenkodex  (vgl.  Kapitel  1.3.2)  halten  wird.  Inwieweit 
bei  statistisch  steigenden  Mitgliederzahlen  sich  auch  die  Anzahl  „schwarzer  Schafe“  erhoht 
ist  nicht  vorherzusehen.  Fur  Nutzer  von  WLANs  ergibt  sich  in  jedem  Falle  ein  Anstieg 
an  Aufklarungsbedarf.  Ob  das  Wissen  um  die  Gefahren  beim  Einsatz  von  WLAN  und 
die  Bereitstellung  von  Werkzeugen  zur  Abschirmung  (z.  B.  nach  IEEE  802.  Hi)  oder  der 
Einfallsreichtum  und  die  Finesse  der  War  Driver  schneller  wachst  bleibt  abzuwarten.  Da 
„ein  drahtloser  Internetzugang  bald  genauso  selbstverstandlich  wie  die  Strom-  und  Wasser- 
Versorung“  [10]  sein  wird,  sollten  Sicherheit  und  Authentizitat  von  Daten  m.  E.  auch  in 
Zukunft  auf  drei  Saulen  aufbauen: 

1.  Verpflichtung  zum  gewissenhaften  Umgang  mit  Software  und  Daten  (nach  Ehren¬ 
kodex  (vgl.  Kap.1.3.2)  bzw.  anhand  des  Normen-  und  Wertegefiiges  unserer  Gesell- 
schaft). 

# 

2.  Zunehmende  Aufklarungsarbeit  der  Anbieter  und  Hersteller. 

3.  Schaffung  eindeutiger  und  durchsetzbarer  Regelungen  durch  den  Gesetzgeber. 

Auf  Basis  eines  star  ken  Normen-  und  Wertegefiiges  in  Verbindung  mit  wirkungsvollen 
Sicherheitsmechanismen  ware  die  zukiinftige  sinnvolle  Gestaltung  eines  sicheren,  global 
verfiigbaren  drahtlosen  Internetzugangs,  nach  den  Beispielen  aus  Anhang  B,  denkbar  und 
wiinschenswert.  Die  Erfahrungen  und  Untersuchungsergebnisse  von  War  Drivern  konnten 
auf  dem  Weg  dorthin  wertvolle  Erkenntnisse  fiber  Sicherheitslficken  und  Abschirmungs- 
unzulanglichkeiten  liefern. 


Literaturverzeichnis 


[1]  G.  Oscar:  Editorial:  Hype  Cycle ,  Funkschau,  Nr.  19,  Coburg,  Germany,  Sep.  2003 

[2]  IEEE:  http://standards.ieee.org,  14.  Jan.  2004 

[3]  KeyNet  AG:  Das  IEEE  und  seine  Aufgaben  - 
http://www.key-net.ch/techsite/pdffiles/AufgabenIEEE.pdf,  14.  Jan.  2004 

[4]  Mohamed  Kallel:  Security  in  Wireless  Networks,  B.  Stiller,  O.  Braun,  A.  Heursch, 
Mobile  Systems  I,  Miinchen,  Germany,  Dez.  2002 

[5]  Gulli.com:  Wardriving  FAQ: 

http://www.gulli.eom/dokumente/faq/wlan.html#2,  14.  Jan.  2004 

[6]  J.  Geier:  Understanding  Wireless  LAN  Routers , 
http://www.wi-fiplanet.com/tutorials/article.php/1586861,  01.  Feb.  2004 

*  [7]  Ad-hoc  !!!! 

[8]  IEEE  Org:  http :  // standards .  ieee .  org/cgi-bin/status?wireless,  23.  Marz  2004 

[9]  C.  Kartes:  Die  Zukunft  von  WLAN  heifit  802.  llg,  Funkschau,  Nr.  10,  Coburg,  Ger¬ 
many,  Mai  2003 

[10]  H.  J.  Rauscher:  Grofibaustelle  Wireless,  Funkschau,  Nr.  22,  Coburg,  Germany, 
Nov.  2003 

[11]  E.  Bloam:  Drahtlos  Messen  und  Testen,  Funkschau,  Nr.  23,  Coburg,  Germany, 
Nov.  2003 

[12]  F.-J.  Kauffels:  Wireless  LANs,  Bonn,  Germany,  2002 

[13]  A.  Krai,  H.  Kreft:  Wireless  LANs  Networker’s  Guide,  Miinchen,  Germany,  Apr.  2003 

[14]  Status  of  Projekt  IEEE  802. llg: 
http://grouper.ieee.org/groups/802/ll/Reports/tgg_update.htm, 

27.  Mrz.  2004 

[15]  Status  of  Projekt  IEEE  802. lli: 

http :  //grouper .  ieee .  org/ groups/802/ 1 1 /Report  s/tgi_update .  htm, 

27.  Mrz.  2004 


27 


28 


War  Driving  -  An  Approach  to  Locate  Open  WLANs 


[16]  C.  Kartes:  WLAN-Sicherheit  heute  und  morgen,  Funkschau,  Nr.  25-26,  Coburg,  Ger¬ 
many,  Dez.  2002 

[17]  M.  Gongolsky:  Der  dmhtlose  LANsinn, 

http : //www. spiegel .de/netzwelt/technologie/O, 1518,241860,00 .html, 

Spiegel  Online,  29.  Mrz.  2004 

[18]  Wi-Fi  Networking  News: 

http://wifinetnews.com/archives/002783.html,  14.  Jan.  2004 

[19]  Wardriving  FAQ:  What  is  Wardriving?, 
http://www.wardriving.info/live/index.php,  20.  Jan.  2004 

[20]  P.  Shipley,  S.  L.  Garfinkel:  An  Analysis  of  Dial-Up  Modems  and  Vulnerabilities  (20 01 ), 
http://www.dis.org/filez/Wardial_ShipleyGarfinkel.pdf,  26.  Jan.  2000 

[21]  Martin  Puaschitz:  WLAN  -  WarDriving  [...], 
http://www.it-academy.cc/content/article_browse.php?ID=593#6,  30.  Jan.  2004 

[22]  Warchalking:  http://www.warchalking.org,  28.  Jan.  2004 

[23]  Deutsches  Wardriving-Portal: 
http://www.wardriving-forum.de/wiki/,  24.  Jan.  2004 

[24]  Mobileaccess.de:  Wireless  LAN  HotSpots  -  in  deiner  nahe, 
http://neu.mobileaccess.de/wlan/index.html?sid=,  24.  Apr.  2004 

[25]  Wardriving:  Liste  Amerikanischer  Organisationen , 
http://www.wardriving.com/links.php,  01.  Feb.  2004 

[26]  God  de  Vader:  Wardriving,  http://users.skynet.be/multibox,  10.  Feb.  2004 

[27]  R.  Flickenger:  Antenna  on  the  Cheap(er,  Chip), 
http://www.oreillynet.com/cs/weblog/view/wlg/448,  30.  Mrz.  2004 

[28]  A.  von  Obert:  WLAN-Reichweite  erhohen 
http://www.techwriter.de/thema/wlan-rei.htm,  30.  Mrz.  2004 

[29]  A.  Hagedorn:  IEEE  802. lli  Sicherheit  in  drahtlosen  lokalen  Netzen,  Diplomarbeit, 
TU  Darmstadt,  Nov.  2003 

[30]  Aerosol  (PRG):  Crack-Tool  zum  Mitschneiden  von  Datenpaketen, 

http://www.stolenshoes.net/sniph/aerosol.html,  30.  Mrz.  2004 

[31]  Colasoft  Capsa  (PRG):  Analyse-Tool  zur  Netzwerkuberwachung, 

http://www.colasoft.com/products/capsa/index.php?id=30916w,  30.  Mrz.  2004 

[32]  HostAP  (PRG):  Crack-Tool  zur  Emulation  eines  APs  mittels  einer  WLAN  Netzwerk- 
karte,  http://hostap.epitest.fi/,  31.  Mrz.  2004 

[33]  Freifunk.wiki: 

http : //www. freifunk.net/wiki/GesetzeUndVorschrif tenDieWLANBetref fen, 

24.  Mrz.  2004 


Dirk  Schindler 


29 


A.l  War  Driving  Foren  in  Europa 


Die  Tabelle  1.3  vermittelt  eine  Ubersicht  iiber  die  Lander  in  denen  War  Driver  bereits 
in  Gemeinschaften  organisiert  sind.  Einige  der  aufgelisteten  Internetauftritte  sind  noch 
neu  und  z.  T.  in  Ausarbeitung.  Es  ist  anzunehmen,  dass  in  Kiirze  weitere  Lander  hinzu 
kommen. 


Tabelle  1.3:  Internetadressen  europaischer  War  Driving  Foren  (Stand:  Mrz.  2004) 


Land: 

Internetadresse: 

Bundesrepublik 

http://www.wardriving-forum.de/wiki,  31.  Jan.  2004 

Belgien 

http://www.wardrivers.be/phpBB2,  29.  Mrz.  2004 

Frankreich 

http://craiefiti.free.fr,  31.  Jan.  2004 

Niederlande 

http:  /  /forum.wirelessnederland.nl/viewtopic.php?t=1724, 

31.  Jan.  2004 

Osterreich 

http://www.wgv.at,  31.  Jan.  2004 

Portugal 

http :  /  /  www.  canariaswireless  .net/  modules .  php?name= 
News&file=article&sid=169,  31.  Jan.  2004 

Schweiz 

http://www.wardriving.ch,  31.  Jan.  2004 

A. 2  Flachendeckender  Zugang 


Verschiedene  Interessensverbande  von  War  Drivern  oder  auch  WLAN-Interessierte  ha- 
ben  sich  die  Aufgabe  gestellt  flachendeckend  freien  Zugang  in/zu  WLANs  zu  ermoglichen 
(FreeNets).  Das  Prinzip,  welches  dabei  zu  Grunde  gelegt  wird  ist  das  folgende:  Nutzer  die 
Providergebiihren  bezahlen,  stellen  Ihre  ungenutzte  Bandbreite  zur  Verfiigung,  so  dass 
Passanten  den  bereitgestellten  Onlinezugang  nutzen  konnen.  Im  Gegenzug  erwarten  die 
einzelnen  Nutzer,  dass  sie  sich  ebenfalls  kostenlos  an  anderen  geographischen  Orten  (z. 
B.  in  der  Stadt)  in  das  Internet  einwahlen  konnen.  Auf  diese  Art  („Geben  und  Nehmen“) 
soli  ein  flachendeckendes  Gesamtnetz  entstehen  iiber  das  sich  Burger  mobil  und  ortsun- 
abhangig  einwahlen  konnen. 

Vorreiter  dieser  Vorhaben  sind  im  Folgenden  tabellarisch  aufgelistet: 
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Name  der 
Gemeinschaft: 

Internetadresse:  1 

NoCatNet 

http://nocat.net,  01.  Feb.  2004 

NoVAWireless 

http://www.cawnet.org,  01.  Feb.  2004 

NYCwireless 

http://www.nycwireless.net,  01.  Feb.  2004 

PersonalTelco 

http://www.personaltelco.net/static/index.html, 

01.  Feb.  2004 

Seattle  Wireless 

htt  p :  // www.  Seattle  wireless  .net/ index .  cgi /Front  Page? 
action=show&redirect=StartSeite,  01.  Feb.  2004 

SFLan 

Wireless  Data 

hhttp://www.archive.org/web/sflan.php,  01.  Feb.  2004 

Tabelle  1.4:  Internetadressen  zur  Errichtung  von  FreeNets  (Stand:  Feb.  2004) 


A. 3  Verzeichnis  der  Abkurzungen  und  Akronyme 


AP 

BSD 

GPS 

DFS 

DHCP 

ETSI 

HiperL  AN /2 

IEEE 

ISO 

LAN 

MAC 

MIC 

MIMO 

OFDM 

OS 

OSI 

PDA 

RAM 

SSID 

TKG 

TPC 

VPN 

WEP 

WiFi 

WLAN 


Access  Point  (Zugangsknoten  fur  schnurlose  Dateniibertragung) 
Berkeley  Software  Design  (basierend  auf  UNIX) 

Global  Positioning  System 

Dynamic  Frequency  Selection  (Dynamische  Frequenzwahl) 

Dynamic  Host  Configuration  Protocol 

Europaisches  Institut  fur  Telekommunikations-Standards 

High  Performance  Radio  Local  Area  Network,  Type  2 

Institute  of  Electrical  and  Electronics  Engineers  („I-triple-E“) 

International  Standardisation  Organisation 

Local  Area  Network 

Media  Access  Control 

Message-Integrity-Check 

Models  and  Infra-structures  for  Mobile  Computing 
Orthogonal  Frequency  Division  Multiplexing 
Operating  System  (Betriebssystem) 

Open  Systems  Interconnection 
Personal  Digital  Assistant 
Random  Access  Memory 
Service  Set  Identifier 
Telekommunikationsgesetzes 
Transmit  Power  Control 
Virtual  Private  Network 
Wired  Equivalency  Privacy 

Wireless  Fidelity  (Kompatibilitatssiegel/Giitesiegel  der  Industrie) 
Wireless  Local  Area  Network 
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Das  Internet  hat  sich  in  letzten  Jahren  als  universales  und  globales  Kommunikationsme- 
dium  etabliert.  Man  verwendet  dieses  riesige  weltweite  Netzwerk  zur  Kommunikation,  um 
verschiedene  verteilte  Standorte  und  Personen  miteinander  zu  verbinden.  Heutzutage  ist 
die  Sicherheit  im  Internet  ein  wichtiges  Thema,  da  die  Datenkommunikation  im  Internet 
nicht  vertraulich  ist.  Die  private  Datenkommunikation  erfordert  jedoch  die  Vertraulichkeit, 
Integritat  und  Authentizitat  der  Informationen.  Diese  Anforderungen  kann  man  mit  der 
Technik  der  virtuellen  privaten  Netzwerke  erfiillen.  In  dieser  Arbeit  werden  zunachst  allge- 
meine  Definition  des  VPNs  erlautert,  sowie  die  typische  VPN-Szenarien,  die  man  uberall 
findet.  Anschliessend  werden  die  Anforderungen  an  VPNs  vorgestellt.  Danach  wird  die 
Sicherheit  von  Virtuellen  Privaten  Netzwerken  anhand  deren  Authentifizierung  und  Ver- 
schliisselungsverfahren  erlautert.  Zudem  werden  verschiedene  Algorithmen  beschrieben. 
Anschliessend  werden  die  breit  verwendeten  VPN-Protokolle  anhand  deren  Zuordnung  zu 
dem  ISO/OSI-Referenzmodell  beschrieben,  sowie  andere  Implementierungen  der  VPN- 
Protokolle.  Im  Fazit  wird  eine  Zusammenfassung  gebildet  und  einen  Vergleich  zwischen 
IPSec  und  SSL- VPN. 
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VPN-Virtuelle  Private  Netzwerke  stellen  eine  sichere  Verbindung  dar.  Sie  bieten  Vertrau- 
lichkeit,  Integritat  und  Authentizitat  der  Informationen.  Von  grofien  Unternehmen,  die 
moglicherweise  zwischen  verschiedenen  Standorten  kommunizieren  bis  zur  privaten  Kom- 
munikation  zwischen  zwei  Rechnern  ist  VPN  die  beste  Losung,  um  eine  sichere  Kommu- 
nikation  und  kostengunstige  Verbindung  herzustellen.  Heutzutage  werden  mehrere  VPN- 
Losungen  angeboten.  Sie  stiitzen  sich  auf  unterschiedlichen  Protokolie  ab. 

Da  das  Internet  grundsatzlich  ein  offenes,  ungeschiitztes  Netz  ist,  besteht  die  Gefahr,  dafi 
ubertragene  Nachrichten  von  Unbefugten  abgehort  oder  manipuliert  werden.  Ein  Beispiel 
ist  eine  Abhorstation  der  Nato  Security  Agency  (NSA)  in  Bad  Aibling,  die  50  km.  sud- 
lich  von  Miinchen  liegt.(s.  Abb. 2.1).  NSA,  der  geheimste  Geheimdienst  der  USA  hort  in 
Deutschland  alle  Telefongesprache,  Faxe  und  E-Mails  ab.  Die  Aufgabe  der  NSA  ist,  jede 
Art  von  auslandischer  Kommunikation,  die  fur  die  Sicherheit  der  Nato  von  Interesse  ist, 
abzuhoren  und  zu  decodieren.  Die  NSA  spielt  im  Internet  eine  wichtige  Rolle,  da  die  NSA 
darauf  drangt,  da6  die  Internet-Software  und  die  Web-Browser  nur  mit  Verschliisselungs- 
verfahren  arbeiten,  die  von  den  Cray-Superrechnern  der  NSA  mit  vertretbarem  Aufwand 
dechiffriert  werden  konnen.[5] 


Abbildung  2.1:  Die  US-Abhorstation  in  Bad  Aibling  [5] 

Wegen  der  Bedrohungen  im  Internet  werden  immer  neue  VPN-Losungen  vorgestellt,  wie 
IPSec-VPN  oder  SSL- VPN.  SSL- VPN  ist  die  neuste  VPN-Losung,  die  von  der  Industrie 
vorgestellt  wird.  Es  bietet  eine  einfachere  Benutzung  als  jede  andere  VPN-Losung.  Aller- 
dings  hat  jede  VPN-Losung  Vor-  und  Nachteile.  Der  Benutzer  muss  entscheiden,  welche 
Losung  fur  seinen  Zweck  am  besten  geeignet  ist. 
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2.2  Virtual  Private  Networks 

2.2.1  Definition 


VPN  steht  fiir  “Virtual-Private-Network11  oder  “virtuelles  privates  Netzwerk11. 

Virtual  bedeutet,  dafi  es  kein  physikalisches  Netz  ist.  Die  Verbindungen  existieren  nur 
wenn  sie  benotigt  werden.[ll] 

Private  bedeutet,  dafi  die  Kommunikation  vertrauenswiirdig  und  nicht  offentlich  durch- 
gefiihrt  wird.[3] 

Eine  allgemeine  Definition,  die  fiir  alle  Arten  von  VPNs  gilt,  ist  “Ein  VPN  ist  ein  Netz¬ 
werk,  das  ein  offentliches  Netzwerk  benutzt,  um  private  Daten  zu  transportieren“[2].  Es 
gibt  zwei  Moglichkeiten,  um  private  Daten  fiber  das  offentliche  Netzwerk  zu  transpor- 
tieren(siehe  Abbildung  2.2).  Die  erste  Moglichkeit  sind  die  so  genannten  Mietleitungen 
oder  Standardfestverbindungen,  die  an  grofie  Netzwerke  oder  Firmen  zur  ausschliefilichen 
Nutzung  vermietet  werden.  Obwohl  diese  teure  Verbindung  nur  vom  Mieter  derselben 
benutzt  werden,  gibt  es  aber  die  Moglichkeit,  dafi  die  Kommunikation  von  dem  Netzbe- 
treiber  abgehort  wird.  Eine  andere  Moglichkeit  ist  die  Benutzung  von  VPN.  Zur  Sicherung 
der  Daten  wird  die  Kommunikation  fiber  das  offentliche  Netzwerk  verschlfisselt  gesendet. 
Diese  Technik  wird  Tunneling  genannt.  Man  kann  mit  der  Tunneling- Technologie  Pakete 
eines  Netzwerkprotokolls  in  Pakete  eines  anderen  Netzwerkprotokolls  kapseln  und  fibers 
Netzwerk  fibertragen.  Das  VPN  kann  teure  Mietleitungen  zwischen  verschiedenen  Stand- 
orten  durch  virtuelle  Verbindungen  ersetzen.  Da  VPN  bei  Bedarf  aktiviert  werden  kann, 
sparen  die  Firmen  Kosten  fiir  ungenutzte  Kapazitaten. 


StancUeitimg 


Abbildung  2.2:  Virtual  Private  Networks 
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2.2.2  VPN-Szenarien 

Es  gibt  heutzutage  zahllose  unterschiedlichen  Arten  von  VPNs,  mit  spezifischen  techni- 
schen  Voraussetzungen.  Man  kann  aber  die  verschiedene  Arten  von  VPNs  in  3  Szenarien, 
unterteilen.[7] 

Host-to-Host 

Diese  Szenario  stellt  die  sicherste  Kommunikation  zwischen  zwei  Rechnern  iiber  das  Inter¬ 
net  dar.  Die  ganze  Verbindung  von  Host  zu  Host  wird  von  dem  Tunnel  mit  den  verschliis- 
selten  Daten  abgedeckt.  Eine  Angriff  auf  der  ganzen  Verbindungslange  kann  ausgeschlos- 
sen  werden.  Voraussetzung  ist  aber,  dass  jeder  Host  an  der  Kommunikationsschnittstelle 
mit  entsprechender  VPN-Software  ausgestattet  sein  muss. 


Computer  2 


Timnelverbindung 


Abbildung  2.3:  VPN-Szenarien  1  [6] 

Gateway-to-Gateway 

Bei  diesem  Szenario  werden  zwei  VPN-Gateways  zur  Netzwerksicherung  vor  den  Intra- 
netzen  positioniert.  Die  Kommunikation  innerhalb  eines  Tunnels  iiber  das  Internet  ist 
verschliisselt.  Bei  dieser  Verbindung  muss  keine  der  lokalen  Arbeitsstationen  mit  speziel- 
ler  VPN-Software  ausgestattet  sein.  Die  ganze  Arbeit  betreffend  die  Sicherheit  erledigen 
die  Gateways,  deshalb  ist  das  VPN  fur  die  Rechner  im  Netzwerk  vollstandig  transparent 
und  senkt  dieses  Szenario  den  Verwaltungsaufwand  fur  den  Administrator  durch  ein  VPN 
erheblich.  Der  Nachteil  dieser  Art  der  Verbindung  ist,  dass  das  Gateway  sehr  leistungsfahig 
sein  muss,  um  alle  Verbindungen  zu  ver-  bzw.  entschliisseln. 


Abbildung  2.4:  VPN-Szenarien  2  [6] 
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Gateway-to-Host 

Bei  der  Gateway-to-Host  Kommunikation  werden  die  mobilen  Clients  bzw.  Tele-Heimarbeiter 
ins  VPN  miteinbezogen.  Dazu  muss  jeder  Rechner  mit  spezieller  VPN-Software  ausgerus- 
tet  sein.  Ein  typisches  Einsatzgebiet  ist  Remote  Access  iiber  unsichere  Transportnetze. 
Eine  strenge  Authentisierung  hat  eine  grofie  Bedeutung,  um  die  Identitat  der  mobilen 
Clients  bzw  Tele-Heimarbeiter  genau  zu  uberpriifen. 


Abbildung  2.5:  VPN-Szenarien  3  [6] 


2.2.3  Anforderungen  an  VPNs 

Wagen  der  verschiedenen  Einsatzgebiete  der  virtuellen  privaten  Netzwerke,  existieren  viele 
verschiedene  Anforderungen  an  VPNs  wie  z.B.  Anforderungen  an  Sicherheit,  Quality-of- 
Service,  Verfiigbarkeit ,  Performance  sowie  anderen  Rahmenbedingungen,  aber  in  dieser 
Seminararbeit  mochte  ich  nur  die  Anforderungen  an  VPNs  betreffend  die  Datensicherheit 
betrachten.  Es  gibt  viele  Anspriiche  im  Bereich  der  Datensicherheit,  die  sich  jedoch  in 
folgende  Aspekte  einteilen  [2]  : 

•  Datenvertraulichkeit 

•  Paket-Authentifizierung 

•  Datenintegritat 

•  Benutzer-Authentifizierung 

1.  Datenvertraulichkeit 

Eine  sehr  wichtige  Anforderung  an  VPN  ist  die  Datenvertraulichkeit.  Die  Daten  auf 
dem  Weg  durch  das  Internet  diirfen  nicht  von  Unbefugten  gelesen  werden. 

Diese  Anforderung  erreicht  man  durch  eine  Verschliisselung  der  Informationen  durch 
den  Absender.  Durch  die  Entschliisselung  beim  Empfanger  werden  die  Informationen 
wieder  lesbar. 
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2.  Paket-Authentifizierung 

Paket-Authentifizierung  garantiert,  dass  die  Nachrichten  oder  ankommende  Pakete 
vom  richtigen  Absender  kommen  und  nicht  von  dritten  mit  gefalschten  Absender- 
adressen  und  neu  berechneten  Priifsummen  geschickt  warden. 

Jedes  ankommende  Paket  muss  ahnlich  wie  bei  einer  Benutzer-Authentifizierung 
authentifiziert  werden.  Die  Vertraulichkeit  der  Daten,  die  nur  dem  Sender  und  dem 
Empfanger  bekannt  sind,  kann  man  durch  symmetrische  Schliissel  oder  Pre-Shared 
Secrets  erreichen. 

3.  Datenintegritat 

Ein  weiterer  Aspekt  der  Sicherheit  ist  die  Datenintegritat.  Der  Empfanger  muss  er- 
kennen  konnen,  ob  ein  ankommendes  Paket  wahrend  des  Transport  verandert  wurde. 
Dazu  wird  die  Paketpriifsumme  mit  speziellen  Verfahren  auf  Basis  von  symmetri- 
schen  Verschltisselungsverfahren  berechnet. 

Die  berechnete  Paketpriifsumme  wird  in  das  Paket  eingefugt.  Die  Schliissel  sind 
nur  dem  Sender  und  dem  Empfanger  bekannt.  Wer  ein  Paket  andern  will,  kann  die 
Priifsumme  nicht  korrekt  berechnen. 

4.  Benutzer-Authentifizierung 

Benutzer-Authentifizierung  ist  eine  sehr  wichtige  Anforderung  bei  Remote-Access- 
VPNs.  Eine  Person,  die  fiber  ein  VPN-Gateway  auf  das  Intranet  zugreift,  muss  seine 
Identitat  nachgewiesen  haben. 

Zahlreiche  Authentisierungsmethoden  konnen  ffir  die  Bedfirfnisse  der  verschiedenen 
VPN-Implementationen  eingesetzt  werden,  z.B.  die  Benutzung  von  Passwort,  Chip- 
karte  oder  die  Uberprfifung  durch  biometrische  Verfahren  wie  Fingerabdruck-Leser. 
Heute  kann  man  sowohl  Authentifizierungsprotokolle  wie  z.B.  PAP  (Password  Au¬ 
thentication  Protocol)  oder  CHAP  (Challenge  Handshake  Authentication  Protocol) 
als  auch  Digitale  Zertifikate  zur  Authentifizierung  einsetzen,  wie  z.B.  Digitale  Zer- 
tifikate  nach  ITU-X. 509-Standard. 


2.3  Die  Sicherheit  Virtueller  Private  Netze 


Die  zu  tibertragenden  Daten  sollen  vor  verschiedenen  Angriffen,  wie  z.B  Denial-of-Service 
oder  Replay- Angriffen  geschfitzt  werden.  Die  Sicherheit  eines  VPN  kann  durch  die  Authen¬ 
tifizierung  und  die  Verschlfisselung  auf  verschiedenen  Schichten  des  ISO/OSI-Schichtenmodells 
realisiert  werden. 
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2.3.1  Authentifizierung 

Man  kann  die  Authentifizierung  in  zwei  verschiedene  Klassen  unterteilen  [2]: 

•  Die  Authentifizierung  einer  natiirlichen  Person 

Hier  wird  die  Identitat  einer  nicht  personlich  anwesenden  Person  gepriift.  Wenn 
beispielsweise  ein  Benutzer  auf  ein  Unternehmensnetzwerk  iiber  ein  Remote-Access- 
VPN  Zugriff  haben  mochte,  muss  er  einem  Zugangs-Kontrollsystem  nachweisen ,  dass 
er  tatsachlich  der  Berechtigte  ist. 

•  Die  Authentifizierung  von  Ubertragungseinheiten  eines  Netzwerkproto- 
kolls,  um  bestimmte  Angriffe  wie  Spoofing  oder  Man-in-the-Middle  ab- 
zuwehren 

Der  Absender  (ein  VPN-Gateway  oder  ein  Router)  eines  Pakets  soil  identifiziert 
werden.  Diese  Authentifizierung  lasst  sich  in  2  Phasen  aufbauen.  Die  erste  Phase 
ist  der  Verbindungsaufbau,  wobei  der  Absender  und  der  Empfanger  sich  gegenseitig 
identifizieren.  Die  zweite  Phase  ist  die  Ubertragungsphase,  hier  werden  die  Pakete 
uberpriift,  ob  sie  wirklich  alle  vom  selben  Absender  kommen. 

Authentifizierungssysteme  und  -protokolle 

Die  folgenden  Verfahren  und  Technologien  werden  in  verschiedenen  Authentifizierungs- 
systemen  eingesetzt. 

•  Password  Authentication  Protocol  (PAP) 

PAP  ist  ein  standardisiertes  Protokoll  fur  Point-to-Point-(PPP)-Verbindungen.  Das 
PAP  ist  ein  einfaches  Protokoll  zum  Austausch  von  Passwortern.  Die  User-ID  und 
das  Passwort  werden  im  Klartext  zu  einem  zentralen  Server  iibertragen,  deswegen 
bietet  das  PAP-Protokoll  nur  geringen  Schutz.[8] 

•  Challenge  Handshake  Authentication  Protocol  (CHAP) 

CHAP  ist  auch  ein  standardisiertes  Protokoll  fur  PPP-Verbindungen  wie  PAP  und 
es  ist  eine  Drei-Phasen-Handshake-Prozedur,  in  der  das  Kennwort  nicht  explizit  wie 
beim  PAP  iibertragen  wird.  Dabei  iibertragt  der  Server  einen  zufallig  generierten 
Schliissel  zum  Anwender.  Das  Passwort  des  Anwenders  wird  mit  diesem  Schliissel 
verschliisselt  und  es  wird  an  den  Server  zuriickgesendet.  Der  Server  entschliisselt 
nun  das  Passwort  mit  seinem  Schliissel  und  iiberpruft  es.[9] 

•  RADIUS 

RADIUS  (Remote  Authentication  Dial  in  User  Service  )  ist  ein  Protokoll  zur  Au¬ 
thentifizierung  von  Remote-Nutzern.  Es  arbeitet  mit  einer  Client-Server- Architektur. 
RADIUS  stellt  Mechanismen  zur  Benutzeridentifizierung  iiber  PAP  und  CHAP,  zur 
ZugrifFskontrolle  iiber  eine  eigene  RADIUS-Datenbank  und  zur  Verwaltung  von  dy- 
namischen  IP-Adressen  bereit.  Die  Passworter  werden  im  Klartext  gespeichert,  aber 
es  gibt  auch  RADIUS-Server,  die  Passworter  verschliisseln  und  wieder  entschliisseln 
konnen. 
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RADWS-Sen/er  RAO!US-S«Vtf 


Benutzer  ISP-Server  Firman-Gateway 


Abbildung  2.6:  Aufbau  eines  VPN  mit  RADIUS-Servern[10] 

2.3.2  Verschlusselungsverfahren 

Es  gibt  zwei  grundsatzliche  Verschlusselungsverfahren,  die  auf  Schliisseln  basieren.  Das 
erste,  die  symmetrische  oder  Secret-Key- Verschliisselung.  Das  andere  ist  die  asymmetri- 
sche  oder  Public-Key- Verschliisselung.  [2] 

1.  Symmetrische  Verschlusselungsverfahren 

Bei  einem  symmetrischen  Verschlusselungsverfahren  kennen  alle  beteiligten  Gegen- 
stellen  nur  einen  geheimen  Schliissel,  den  man  zur  Verschliisselung  und  zur  Ent- 
schliisselung  verwendet.  Da  es  nur  einen,  geheimen  Schliissel  gibt,  spricht  man  bei 
Kommunikation  mit  symmetrischer  Verschliisselung  oft  von  “private  key  communi¬ 
cation"  .  Das  Grundprinzip  funktioniert,  wie  in  Abb. 2. 7  dargestellt.  Zunachst  mufi 
der  Schliissel  iiber  einen  sicheren  Kanal  ausgetauscht  werden.  Dieser  Schliissel  dient 
dem  Sender  zur  Verschliisselung  des  Klartexts  und  dem  Empfanger  zur  Entschliis- 
selung  des  Chiffretexts.  Die  Teilnehmer  konnen  danach  die  Nachrichten,  die  vom 
Sender  gesendet  werden,  entschliisseln.  Selbst  kann  der  Sender  die  Nachrichten  fiir 
den  Empfanger  verschliisseln.  [12] 


Verschliisselung  NaohrichtenubermitBung  Entschlusselung 


Abbildung  2.7:  Eine  symmetrische  Verschliisselung[12] 
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Die  symmetrischen  Verfahren  verwenden  normalerweise  entweder  die  Datenblock- 
oder  die  Datenstrom-Verschliisselung.  Bei  der  Datenblock-Verschliisselung  werden 
jeweils  komplette  Blocke  einer  bestimmten  GroBe  mit  einem  Schliissel  verschliis- 
selt.  Bei  der  Datenstrom-Verschliisselung  wird  ein  Datenstrom  so  lange  fortlaufend 
verschliisselt,  bis  der  Eingangsdatenstrom  vollstandig  verarbeitet  wurde.  [2] 

•  Der  Data  Encryption  Standard  (DES) 

DES  wurde  bereits  Mitte  der  siebziger  Jahre  von  IBM  entwickelt.  Er  ist  ein 
Standard  des  US-amerikanischen  National  Bureau  of  Standards  (NBS)  und  ist 
in  der  Federal  Information  Processing  Standard  Publication  (FlPS-Pub)  46- 
2  beschrieben.  DES  ist  ein  Blockverschliisselungs- Verfahren  und  ist  bis  heute 
noch  das  am  weitesten  verbreitete  Verschliisselungs- Verfahren.  Der  Schliissel 
hat  eine  Lange  von  64-Bit,  aber  jedes  achte  Bit  dient  einer  Paritatspriifung 
und  tragt  nicht  zur  Verschliisselung  bei.  Heutzutage  ist  56-Bit  Schliissellange 
unsicher  und  mit  spezieller  Hardware  der  NS  A  oder  einem  Brute-Force- Angriff 
ist  DES  innerhalb  weniger  Stunden  knackbar.  [2] 

•  Triple-DES 

DES  gait  jahrelang  als  ein  sicheres  Verfahren,  sein  einziger  Nachteil  ist  die  gerin- 
ge  Schliissellange.  Deshalb  schaltet  man  drei  DES-Verschliisselungen  mit  zwei 
oder  drei  Schliisseln  hintereinander.  Der  Klartext  wird  mit  dem  ersten  Schliissel 
verschliisselt,  mit  dem  zweiten  entschliisselt  und  wieder  mit  dem  dritten  ver- 
schlusselt.  Deshalb  ist  Triple-DES  3  fach  langsamer  als  Standard-DES,  dafiir 
ist  es  aber  sicherer.  Man  muss  beachtet,  dafi  wenn  der  erste  Schliissel  und  der 
zweite  oder  der  zweite-  und  der  dritte  Schliissel  gleich  sind,  dann  funktioniert 
3DES  wie  Standard-DES.  Aufgrund  der  Schliissellange  gilt  Triple-DES  derzeit 
noch  als  sicheres  Verfahren  im  Gegensatz  zum  einfachen  DES.  [13] 

Plaintext 


Key  1 
Key  2 
Key  3 


Ciphertext 

Abbildung  2.8:  Triple-DES  Verschliisselung[12] 

•  Advanced  Encryption  Standard  (AES) 

Das  amerikanische  National  Institute  of  Standards  and  Technology(NIST)  hat 
im  Dezember  2000  den  Rijndael- Algorithm  als  AES  ausgewahlt.  Dieser  Al- 
gorithmus  wurde  von  Dr.  Joan  Daemen  von  Proton  World  International  und 
von  Dr.  Vincent  Rijmen  von  der  katholischen  Universitat  Leuven  in  Belgien 
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entwickelt.  AES  ist  der  Nachfolger  fiir  DES  bzw.  Triple-DES  und  ist  ein  Block- 
verschliisselungsalgorithmus.  [2]  Rijndael  ist  ein  Blockchiffrierverfahren.  Die 
BlockgroBe  betragt  128,  192  und  256  Bit,  sowie  variable  Schliissellangen  mit 
128,  192  und  256  Bit  (AES-128,  AES-192  bzw.  AES-256).  Nach  Angaben  des 
NIST  wiirde  eine  Maschine,  die  einen  DES-Schliissel  in  einer  Sekunde  knackt, 
fur  einen  128-bit  AES-Schliissel  149  Billionen  Jahre  benotigen[14] 

•  International  Data  Encryption  Standard  (IDEA) 

IDEA  wurde  von  Xueija  Lai  und  James  Massey  entwickelt.  IDEA  ist  ein  Block- 
verschliisselungsalgorithmus  mit  einer  Blocklange  von  64  Bit  und  ,  einer  Schliis¬ 
sellange  von  128  Bit.  IDEA  ist  fiir  nichtkommerzielle  Anwendung  lizenzfrei 
erhaltlich.  Bei  kommerzieller  Nutzung  muss  eine  Lizenzgebiihr  an  den  Inhaber 
der  Rechte(die  Firma  Ascom)  gezahlt  werden.[3]  Wegen  der  groBen  Schliissel- 
lange  kann  IDEA  heutzutage  als  sicherster  Blockchiffrieralgorithmus  angesehen 
werden.[15] 

•  RC4 

RC4  wurde  im  Jahr  1987  von  Ron  Rivest  fiir  die  Firma  RSA  Data  Security 
Inc.(RSADSI)  entwickelt.  Es  handelt  sich  um  eine  Stromchiffrierung,  die  mit 
variabler  Schliissellange  arbeitet.  Die  variable  Schliissellange  kann  bis  zu  2.048 
Bit  lang  sein.  Jedes  Zeichen  wird  einzeln  verschliisselt.  Der  Algorithmus  war 
ganze  sieben  Jahre  lang  geheim,  bis  1994  jemand  anonym  den  Quellcode  ver- 
offentlicht  hat.  Dieser  Algorithmus  ist  etwa  fiinf  bis  zehn  mal  so  schnell  wie 
DES.  [3] 

•  Blowfish 

Blowfish  ist  eine  Blockchiffrierung  und  wurde  1993  von  Bruce  Schneier  entwi¬ 
ckelt.  Die  BlockgroBe  betragt  64-Bit,  die  Schliissellange  ist  variabel  und  kann 
bis  zu  448  Bit  reichen.  Weiterhin  ist  Blowfish  auf  32-Bit-Prozessoren  wesentlich 
schneller  als  DES  und  bisher  ist  kein  Makel  am  Blowfish- Algorithmus  bekannt. 

[3] 

2.  Asymmetrische  Verschliisselungsverfahren 

Asymmetrische  Verfahren  verwenden  zwei  verschiedene  Schliissel.  Auf  der  einen  Sei- 
te  ist  der  offentliche  Schliissel  (public  key)  zum  Verschliisseln(Chiffrierung)  und 
auf  der  anderen  Seite  ist  ein  privater  Schliissel  (private  key)  zum  Entschliisseln 
(Dechiffrierung).[2]  Da  ein  Schliissel  offentlich  zuganglich  gemacht  werden  muss, 
wird  dieses  Verfahren  auch  Public  Key- Verfahren  genannt.  Basis  der  Asymmetri- 
schen  Verschliisselungsverfahren  sind  Einweg-Funktionen.  Dies  sind  Funktionen,  die 
ohne  groBeren  Aufwand  berechenbar  sind,  bei  denen  aber  die  Berechnung  der  in- 
versen  Funktionen  sehr  schwierig  ist.  Wenn  das  Inverse  einer  Einweg-Funktion  bere¬ 
chenbar  sein  soli,  fiihrt  dies  zu  den  Einweg-Funktionen  mit  Falltiir (trapdoor  oneway- 
functions).  Mit  Hilfe  einer  geheimzuhaltenden  Zusatzinformation  ist  die  Berechnung 
des  Inversen  schneller  machbar.  Asymmetrische  Verschliisselungsverfahren  sind  etwa 
1000  bis  10000  Mal  langsamer  als  symmetrische  Verfahren.  Wegen  des  geringeren  Da- 
tendurchsatzes  bei  der  Ver-  und  Entschliisselung  werden  sie  nur  zur  Authentikation 
und  zum  Austausch  des  Schliissels  fiir  die  symmetrische  Verschliisselungsverfahren 
benutzt.[3]  Die  bekanntesten  Public-Key- Verfahren  sind  RSA  und  Diffie-Hellman. 
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Abbildung  2.9:  Asymmetrische  Verschliisselung[12] 


•  Das  Diffie-Hellman-Verfahren 

Diffie-Hellman-Verfahren  wurde  1976  von  Whitfield  Diffie  und  Martin  Heilman 
entwickelt.  Dieses  sehr  altes  Verfahren  kann  nicht  zum  Ver-  und  Entschliisseln 
von  Daten  verwendet  werden.  Es  kann  nur  zur  Erzeugung  von  symmetrischen 
Schliisseln  benutzt  werden.  [2]  Das  Verfahren  beruht  auf  dem  bis  heute  unge- 
losten  mathematischen  Problem  des  diskreten  Logarithmus.[16] 

•  Das  RSA- Verfahren 

Das  RSA- Verfahren  ist  nach  Entdeckern  Ronald  Rivest,  Adi  Shamir  und  Leo¬ 
nard  Adleman  vom  Massachusetts  Institute  of  Technology  benannt.  Der  Un- 
*  terschied  zum  Diffie-Hellman-Verfahren  ist,  dafi  man  mit  RSA  Daten  ver-  und 

entschliisseln  kann.  Die  Funktion  von  RSA  beruht  auf  dem  mathematischen 
Problem,  dafi  die  Zerlegung  einer  grofien  Zahl  in  ihre  Primfaktoren  sehr  auf- 
wandig  ist.  [2] 

3.  Hashfunktionen 

Hashfunktionen  sind  keine  Funktionen,  zum  Ver-  oder  Entschliisseln.  Sie  berech- 
nen  einen  kurzen  Ausgangswert  fester  Grofie(Hashwert)  eines  beliebig  langen  Ein- 
gangswerts.  Dieser  Hashwert  kann  als  eine  Art  Priifsumme  bezeichnet  werden.  Der 
Hashwert  wird  digital  unterschrieben  und  an  die  Nachricht  angehangt.  Der  Empfan- 
ger  wendet  auf  die  Nachricht  dieselbe  Hashfunktion  an  und  vergleicht  das  Ergebnis 
mit  dem  mitgeschickten  durch  die  digitale  Unterschrift  des  Senders  authentifizier- 
ten  Hashwert.  Da  eine  kleine  Anderung  in  der  Datenmenge  grofie  Auswirkungen  auf 
den  Hashwert  hat,  kann  man  Manipulationen  an  den  Originaldaten  sofort  merken. 
Damit  kann  die  Integritat  einer  Nachricht  sichergestellt  werden.  [18] 

Message  Digest  (MD5) 

MD4  (  Message  Digest  No.  4  ),  dokumentiert  in  RFC  1320,  wurde  von  Ron  Ri¬ 
vest  (  RSA  Data  Security  )  entwickelt.  Dieser  Algorithmus  erzeugt  einen  128-bit 
Hash- Wert  in  3  Runden  mit  einer  extrem  schnellen  Funktion.  Leider  fiihrt  diese  Ge- 
schwindigkeit  auch  dazu,  dass  MD4-verschliisselte  Daten  schnell  wieder  entschliisselt 
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werden  konnen,  deshalb  wurde  ein  Nachfolger  von  MD4  entwickelt.  MD5  ist  ein  ver- 
besserter  Nachfolger  von  MD4  und  er  wurde  ebenfalls  von  Ron  Rivest  entwickelt. 
MD5  erzeugt  aus  einem  Eingangswert  beliebiger  Lange  einen  128-Bit-Hashwert  in 
4  Runden.  Dieses  Verfahren  findet  man  nicht  nur  in  IPSec,  sondern  auch  in  vielen 
anderen  Protokollen  wie  CHAP,  L2TP.[3] 

Secure  Hash  Algorithm  (SHA-1) 

Am  Anfang  der  neunziger  Jahre  entwickelte  der  National  Institute  of  Standards  and 
technology(NIST)  zusammen  mit  der  National  Security  Agency(NSA)  den  Secure 
Hash  Algorithm  fur  den  Einsatz  mit  dem  Digital  Signature  Standard.  Der  Secure 
Hash  Algorithm (SH A)  erzeugt  einen  160  Bit  langen  Hashwert  und  gilt  als  sehr 
sicher.  [3] 

Hash-based  Message  Authentication  Code  (HMAC) 

Hash-based  Message  Authentication  Code(HMAC)  ist  kein  Hashalgorithmus,  son¬ 
dern  ein  Mechanismus  zur  Authentifizierung  von  Nachrichten,  der  kryptografische 
Hashfunktionen  wie  MD5  oder  SHA  verwendet.  Die  kryptografische  Starke  des 
HMAC  hangt  von  den  Eigenschaften  der  zugrunde  liegenden  Hashfunktion  ab.[17] 

2.4  Zuordnung  der  VPN-Protokolle  zu  den  7  Schich- 
ten  des  ISO/OSI-Referenzmodelles 

Heutzutage  gibt  es  auf  dem  Internet-Markt  viele  Sicherheitsprotokolle,  die  zur  Realisie- 
rung  eines  VPN  verwendet  werden  konnen.  Die  Protokolle  konnen  in  die  verschiedenen 
Schichten  des  ISO/OSI-Referenzmodelles  eingeordnet  werden. 


Application  Layer  (Schicht  7) 


Presentation  Layer  (Schicht  6) 

. . — y— 'I  ix,  -'/t;  "4*  ^""5 

Session  Layer  (Schicht  5) 


Transport  Layer  (Schicht  4) 


Network  Layer  (Schicht  1 ) 


Link  Layer  (Schicht  2) 


Physical  Layer  (Schicht  I) 


z.B.  HTTPS,  SSL 


z.B.  IPSec 

z.B.  L2TP,  PPTP 


Abbildung  2.10:  OSI-Schichten 
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Durch  diese  Zuordnung  lassen  sich  drei  unterschiedliche  VPN-Typen  klassifizieren.  Es  sind 
die  VPN  der  Anwendungsebene  (Application-Layer),  der  Netzwerkebene  (Network-Layer) 
und  der  Netzwerkverbindungsebene  (Link-Layer).  In  dieser  Arbeit  werden  die  haufig  ver- 
wendeten  Protokolle  betrachtet:  PPTP,L2TP,IPSec  und  SSL. 

1.  PPTP  :  Pomt-to-Point-Tunneling-Protokoll 

Das  Punkt-zu-Punkt  Tunneling  Protokoll(PPTP)  wurde  von  verschiedenen  grofien 
Firmen  wie  Microsoft,  Ascend  Communications,  3Com  und  anderen  zusammen  ent- 
wickelt.  PPTP  ist  eine  Erweiterung  des  Point-to-Point  Protocol  (PPP)  und  es  ist 
von  IETF(Internet  Engineering  Task  Force)  als  Standardprotokoll  fiir  das  Internet- 
Tunneling  vorgeschlagen  .  Das  PPTP  wurde  urspriinglich  fiir  “Remote  Access  Ser¬ 
ver"  entwickelt  und  Microsoft  hat  PPTP  erstmals  in  Windows  NT4.0  integriert. 
PPTP  kapselt  PPP-Pakete  in  IP-Pakete,  dadurch  konnen  andere  Pakete  wie  IPX- 
oder  NetBUI-Paketen  getunnelt  werden.  Aber  je  Kommunikationspaar  kann  nur 
ein  Tunnel  aufgebaut  werden.  Der  Tunnel  besteht  aus  zwei  Ubertragungskanalen: 
einer  fiir  die  Nutzdaten,  der  andere  fiir  die  Kontrolle  der  Verbindung.  Uber  die- 
sen  Kontroll-Kanal  signalisieren  sich  die  Systeme  Verbindungsauf-  und  -abbau.  Fiir 
die  Authentifizierung  der  Kommunikationspartner  setzt  PPTP  auf  die  von  PPP 
bereitgestellten  Mechanismen.  Diese  sind  das  Password  Authentication  Protocol 
(PAP)  oder  das  Challenge  Handshake  Protocol  (CHAP).  Die  Verschliisselung  der 
Daten  erfolgt  uber  RC4-Verfahren  entweder  mit  einem  40-Bit-Schliissel  fiir  den  nicht 
amerikanischen  Markt,  oder  128-Bit-Schliissel.  USA-Exportgesetze  stufen  128-Bit- 
Verschliisselungstechnik  als  militarische  Technologie  ein. [20].  Obwohl  man  PPTP 
noch  heute  verwendet,  findet  keine  Weiterentwicklung  mehr  statt.  Wegen  der  nicht 
geniigenden  Sicherheit  bei  der  Authentifizierung  und  Datenverschliisselung  wird 
PPTP  immer  weniger  benutzt  und  durch  andere  Verfahren  eingesetzt. 

2.  L2TP  :  Layer-2-Tunneling-ProtokoIl 

Layer-2- Tunneling-Protokoll  wurde  von  IETF  als  ein  Standardprotokoll  veroffent- 
licht.  Es  arbeitet  auf  der  Schicht  2  des  ISO/OSI-Schichtenmodells.  L2TP  ist  ei¬ 
ne  Verbesserung  und  Weiterentwicklung  zweier  nicht  standardisierter  Protokolle, 
des  Point-to-Point-Tunneling-Protocol  (PPTP)  und  des  Layer-2-Forwarding  (L2F). 
L2TP  ist  ein  reines  Tunneling-Protokoll  auf  PPP-Ebene,  das  auch  andere  Protokolle 
als  nur  IP  einkapseln  kann.  In  L2TP  sind  keine  Sicherheitsfunktionen  wie  Authen¬ 
tifizierung  oder  Datenverschliisselung  verfiigbar.  Innerhalb  des  Tunnels  fibertragt 
L2TP  zwei  unterschiedliche  Datenstrome.  Zum  einen  die  Kontrollnachrichten,  zum 
anderen  die  Nutzdaten.  Wahrend  der  Kontrollkanal  fiber  eine  gesicherte  Verbindung 
gesendet  wird,  stellt  L2TP  keine  Moglichkeit  zur  Verffigung,  die  Nutzdaten  zu  si- 
chern.  Sicherheitsmafinahmen  werden  auf  anderen  Ebenen  eingesetzt  wie  auf  der 
Netzwerkebene (  z.B.  IPSec)  oder  auf  applikationsnahen  Ebenen(z.B.  SSL). [2]  L2TP 
erlaubt  eine  Authentifizierung  auf  der  Basis  von  PAP  oder  CHAP  und  es  bietet  die 
Moglichkeit,  multiple  Tunnels  aufzubauen.  Als  Bestandteil  von  Windows  2000  hat 
die  Benutzung  des  L2TP  weiter  zugenommen. 
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3.  IPSec 

IPsec  war  urspriinglich  fur  IP  Version  6  geplant.  Fur  IPv6  bietet  IPSec  die  Verschliis- 
selung  auf  Netzwerkebene,  also  auf  der  Schicht  3  des  OSI-Schichtenmodells.  IPSec 
ist  eine  neue  Technik,  die  PPTP  ablosen  soli,  weil  sie  mehr  Sicherheitsmafinahmen 
als  PPTP  anbieten.  Im  Gegensatz  zur  IP- Version  4  werden  zwei  zusatzliche  Header 
gegeben,  die  zu  Zwecken  der  Authentifizierung  des  Absenders  und  Verschliisselung 
definiert  werden.  Die  zusatzlichen  Header  bei  IPv6  sind  Authentication  Header  (AH) 
und  Encapsulated  Security  Payload  (ESP).  IPSec  wurde  aber  auch  mit  IP-Version  4 
implementiert,  wobei  eine  Erweiterung  des  normalen  IP-Header  stattfindet.  Die  Au¬ 
thentifizierung  des  Absenders  wird  durch  RSA,  Pre-Shared  Keys  oder  X-509  Zertifi- 
katen  sichergestellt.  Dazu  werden  Schliissel  der  Kommunikationspartner  per  Internet 
Key  Exchange(IKE)  ausgetauscht.  Die  in  IPSec  haufig  verwendeten  Algorithmen  zur 
Verschliisselung  der  Daten  sind:  DES  mit  einem  56  Bit  langen  Schliissel,  Triple-DES 
mit  168  Bit-Schliissel,  IDEA  mit  einem  128  Bit  langen  Schliissel  oder  Blowfish  mit 
448  Bit  grofiem  Schliissel. 

IPSec  bietet  dem  Benutzer  zwei  Betriebsmodi,  Der  Tunnel  Modus  und  der  Trans- 
portmodus.  Diese  konnen  fur  unterschiedliche  Einsatz-Szenarien  eingesetzt  werden. 

(a)  Tunnelmodus 

Der  Tunnelmodus  wird  benutzt,  um  das  gesamte  IP-Paket  in  die  Nutzdaten 
eines  IPSec-Pakets  einzupacken.  Ein  IPSec-Header  wird  vor  das  IP-Paket  und 
zusatzlich  ein  weiterer  IP-Header  eingefiigt.  Der  Tunnelmodus  kann  in  alien 
drei  Einsatzszenarien  verwendet  werden 

(b)  Transportmodus 

Im  Transportmodus  wird  der  IP-Header  des  ungesicherten  IP-Pakets  iiber- 
nommen  und  nur  sein  Datenteil  verandert.  Der  IPSec-Header  wird  zwischen 
dem  IP-Header  und  dem  Header  des  iibergeordneten  Protokolls  eingefiigt.  Der 
Transportmodus  kann  ausschliefilich  in  Host-to-Host-Einsatzszenario  benutzt 
werden,  da  die  Kommunikationsendpunkte  auch  gleichzeitig  die  Sicherheits- 
endpunkte  sind.  [2] 

•  Das  Authentication-Header-Protokoll  (AH) 

Authentication  Header  ist  ein  IPSec-Protokoll,  das  die  Datenvertraulichkeit 
anbietet.  Die  Aufgabe  des  AH  sind  die  Authentifizierung  der  Datenpakete 
und  die  Datenintegritat.  Ausserdem  bietet  es  auch  den  Schutz  vor  Replay- 
Angriffen.  Zum  Schutz  der  Datenintegritat  und  zur  Authentifizierung  werden 
Hash-Algorithmus:  SHA  oder  MD5  eingesetzt.  Das  AH  wird  im  Tunnelmodus 
und  im  Transportmodus  eingesetzt  wie  in  Abb. 2. 11  gezeigt. 
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Abbildung  2.11:  Das  Authentication-Header-Protokoll(AH)[28] 


•  Das  Encapsulating-Security-Payload-Protokoll  (ESP) 

Das  Encapsulating-Security-Payload-Protokoll  bietet  fast  gleiche  Sicherheits- 
funktionen  wie  beim  AH,  aber  es  bietet  zusatzlich  noch  die  Datenverschliisse- 
lung.  Dazu  wird  ein  Teil  des  IP-Pakets  verschliisselt.  Im  Tunnelmodus  werden 
Applikations-Header,  TCP/UDP-Header  und  Daten  verschliisselt,  wahrend  im 
Transportmodus  nur  TCP/UDP-Header  und  Daten  verschliisselt  werden.  Wie 
beim  AH  benutzt  ESP  zum  Schutz  der  Datenintegritat  und  zur  Authentifizie- 
rung  einen  Hash-Algorithmus,  SHA  oder  MD5. 
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Abbildung  2.12:  Das  Encapsulating-Security-Payload-Protokoll(ESP)[28] 
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Abbildung  2.13:  Ubersicht[l] 


4.  SSL- VPN 

Das  SSL-Protokoll  wurde  urspriinglich  von  Netscape  entwickelt.  Die  derzeit  aktu- 
ellste  Version  des  SSL-Protokolls  ist  die  Version  3.0.  Zwischen  zwei  Rechnern  konnen 
mit  SSL-Protokoll  ein  oder  mehrere  Sitzungen  auf  der  aktuellen  Basis  einer  128bit 
Verschliisselung  aufgebaut  werden.  Das  Protokoll  lauft  im  OSI-Schichtenmodell  zwi¬ 
schen  der  Anwendungs-  und  Transportschicht  und  bietet  Authentizitat,  Vertraulich- 
keit  und  Unversehrtheit  der  Daten  wie  IPSec.  SSL  benutzt  sowohl  asymmetrische 
Verschliisselungsverfahren  als  auch  symmetrischen  Verschliisselungsverfahren.  Das 
SSL  Protokoll  besteht  aus  mehreren  Protokolle[23](siehe  Abb.  2.14)  Das  Handshake 
Protokoll  dient  dazu,  einen  Verschlusselungsalgorithmus  auszuwahlen  und  die  Au- 
thentifizierung  eines  Clients  mit  einem  Server  zu  ermoglichen.  Die  Authentifizierung 
des  Kommunikationsteilnehmers  wird  mit  Hilfe  von  Zertifikaten  von  Zertifizierungs- 
instanzen  (Certification  Authorities,  CAs)  realisiert.  Die  Daten  hoherer  Protokolle 
werden  durch  SSL  Record  Protokoll  fragmentiert,  komprimiert  und  verschliisselt  und 
an  das  untere  Transportprotokoll  weiter  geleitet.  Dieses  Record  Protokoll  realisiert 
die  Vertraulichkeit,  Integritat  und  Authentizitat  der  zwischen  Client  und  Server  ver- 
sendeten  Daten.  Das  weitere  Protokoll,  Change  Cipher  Spec-Protokoll,  regelt  den 
Wechsel  zu  einem  anderen  Verschlusselungsalgorithmus.  Das  Alert  Protokoll  dient 
dazu,  Fehlermeldungen  weiterzuleiten  und  das  Application  Data  Protokoll  reicht  die 
Daten  des  oberen  Protokolls  an  das  Record  Protokoll  weiter.  Der  Vorteil  des  SSL- 
Protokolls  ist  die  Moglichkeit,  jedes  hohere  Protokoll  auf  Basis  des  SSL  Protokolls 
zu  implementieren.  Damit  ist  eine  Unabhangigkeit  von  Applikationen  und  Syste- 
men  gewahrleistet.  SSL- VPN  wurde  von  der  Industrie,  als  neue  Losung  fur  Remote 
Access  bzw.  Szenario  3(Gateway-to-Host),  entwickelt. 

Fur  den  Schliisselaustausch  wahrend  des  Handshakes  stehen  die  Verfahren  RSA 
und  Diffie-Hellman  zur  Verfugung.  Zur  Verschliisselung  der  Daten  konnen  folgende 
Algorithmen  verwendet  werden:  RC4,  DES  und  IDEA. 

Vorteil  bei  dieser  Losung  ist  der  uneingeschrankten  Fernzugriff  auf  Unternehmens- 
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Abbildung  2.14:  Das  SSL-Schichtenmodell[23] 

applikationen  liber  das  Internet  von  einem  Endgerat.  Bei  diesem  Vorteil  besteht 
aber  dennoch  eine  Gefahr,  wenn  das  Endgerat  nicht  sicher  ist  z.B.  ein  Computer  im 
Internetcafe  oder  ein  von  Viren  verseuchter  Computer. 

SSL  VPNs  konnen  in  3  Kategorien  eingeordnet  werden  [24]: 

•  Application  layer  proxy 

•  Protocol  redirectors 

•  Remote  control  enhancers 

Application  layer  proxy 

Application  layer  proxy  ist  die  einfachste  Form  des  SSL- VPN,  weil  sie  eine  Ver- 
schliisselungsschicht  zwischen  die  Applikation(Schicht  7)  und  die  darunterliegende 
Schichten  des  ISO/OSI  Stacks  legen.  Dadurch  werden  alle  Daten,  die  die  Appli¬ 
kation  sendet,  verschliisselt  und  alle,  die  sie  empfangt,  entschliisselt.  Von  einem 
“Applikation  Layer  Proxy"  spricht  man,  wenn  der  Secure  Socket  Layer  (SSL)  in  die 
Applikation,  z.B.  einen  Browser  oder  eine  E-Mail  Client  integriert  ist.Es  wird  haufig 
bei  E-Banking  und  E-Commerce  benutzt.  Da  man  kein  zusatzliche  Programme  fur 
VPN  auf  dem  Rechner  installieren  miissen,  wird  dieses  Verfahren  auch  Clientless 
genannt. 
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Abbildung  2.15:  SSL- VPN  :  Application  layer  proxy 
Protocol  redirectors 

Dieses  Verfahren,  Protocol  redirectors,  wird  benutzt,  wenn  das  SSL  Protokoll  nicht 
in  die  Application  integriert  ist.  Bei  diesem  Verfahren  muss  ein  SSL-Client  Pro- 
gramm  wie  z.B.  Java-Applets  und  Active-X-Controls  heruntergeladen  und  installiert 
werden.  Die  Daten  werden  durch  Port  Forwarding  von  Schicht  3  zum  SSL-Client  um- 
geleitet  und  sie  werden  von  dort  weiter  zu  einem  anderen  Rechner  gesendet(siehe 
Abb. 2. 16). 


Abbildung  2.16:  SSL- VPN  :  Protocol  redirectors 

Remote  control  enhancers 

Remote  control  enhancers  bietet  SSL-Verbindung  fur  existierende  remote  control 
Produkte,  wie  Windows  Terminal  Services.  Die  SSL-Funktionalitat  und  Web-Browser 
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Unterstiitzung  werden  ins  System  integriert,  dadurch  kann  jede  Applikation,  die  auf 
einem  solchen  System  lauft,  die  SSL-Funktion  benutzen. 

5.  Implementierung  der  VPN-Protokolle 

Heutzutage  werden  verschiedene  VPN-Losungen  von  unterschiedlichen  Herstellern 
auf  den  Markt  gebracht.  Sie  werden  auf  verschiedenen  Betriebssystemen  implemen- 
tiert  wie  Windows  oder  Linux.  Eine  bekannte  Implementierung  ist  FreeS /WAN  in 
Linux.  Es  ist  eine  Implementierung  des  IPSec-Protokolls.  Eine  andere  ist  Open- 
VPN.  Das  Open  VPN  verwendet  ein  Standardprotokoll:  Transport  Layer  Security 
(TLS)[27]  und  ist  unter  Linux  implementiert.  TLS  ist  der  Nachfolger  des  SSL- 
Protokolls  von  Netscape  und  benutzt  X-509  Zertifikaten  zur  Authentifizierung  wie 
SSL.  Die  CIPE(Crypto  IP  Encapsulation)  ist  eine  Implementierung,  die  sowohl  un¬ 
ter  Linux  als  auch  unter  Windows  verfiigbar  ist.  Die  CIPE  verpackt  IP~Pakete  ver- 
schliisselt  in  UDP-Paketen  und  die  Pakete  werden  iiber  UDP-Ports  weitergesendet. 
Zur  Authentifizierung  wird  ein  Public-Key- Verfahren  eingesetzt.[27] 

Neben  Softwareimplementierung,  existieren  heute  auch  mehrere  VPN-Hardware- 
Losungen.  Eine  bekannte  Losung  ist  das  System  der  Firma  Cisco.  Cisco  bietet 
verschiedene  Hardwarelosungen  mit  integrierten  VPN-Servern  an.[l],  Wegen  dem 
extra  eingebaute  Chip,  der  die  Verschliisselung  der  Daten  iibernimmt,  bietet  das 
System  sehr  hohe  Performance.  Ausserdem  ist  es  recht  resistent  gegen  Angriffe,  da 
es  ein  CiscoBetriebssystem  benutzt.  Allerdings  muss  ein  spezielles  Programm  auf 
jedem  Rechner  im  Netzwerk  installiert  werden.  Eine  andere  Hardware-Losung  ist 
auf  Netzwerkkarte  z.B.  Intel  Pro/lOOS  implementiert. [25].  Sie  bietet  keine  komplet- 
te  Losung  wie  bei  den  VPN-Geraten  von  Cisco,  sondern  sie  hilft  der  CPU  bei  der 
Datenverschliisselung  und  sie  wird  fur  IPSec-VPN  gebaut. 


2.5  Zusammenfassung 


Heute  existieren  viele  verschiedene  VPN-Losungen  fiir  das  Internet.  Sie  werden  fur  un- 
terschiedliche  Einsatzbereiche  entwickelt.  Zur  Zeit  im  Bereich  des  Mobile-Systems  sind 
IPSec-VPN  und  SSL- VPN  die  neuste  Technik.  Obwohl  SSL- VPN  von  der  Industrie  als 
die  bessere  Technik  bezeichnet  wird,  kann  es  trotzdem  IPSec-VPN  nicht  ersetzen.  Beide 
Verfahren  bieten  gleichwertige  Sicherheit,  aber  man  braucht  bei  IPSec-VPN  eine  auf- 
wendigere  Konfiguration.  Transparente  Tunnel  werden  mittels  IPSec-VPN  aufgebaut.  Da 
IP-Sec  als  Schicht  3  Verschliisselung  tiefer  in  das  System  eingreift  als  SSL- VPN  auf  Schicht 
7,  mufi  man  dafiir  Administratorrechte  besitzen  und  die  Konfiguration  ist  aufwendiger. 
Bei  SSL- VPN  mufi  praktisch  nur  eine  Applikation  mit  SSL-Unterstiitzung  wie  z.B.  ein 
Web-Browser  installiert  werden.  Kann  allerdings  eine  vorhandene  Applikation,  da  die 
Quelltexte  nicht  vorhanden  sind,  nicht  um  SSL  oder  TLS  erweitert  werden,  so  mufi  auf 
das  Protocol  Redirector  Verfahren  zuriickgegriffen  werden.  Deshalb  kann  man  heute  nicht 
sagen,  welche  Losung  am  besten  oder  fiir  alle  Falle  geeignet  ist. 
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Kapitel  3 

Realtime  Networking  in  Wireless 
and  Wired  Networks 

Ronny  Nantke 


Diese  Arbeit  beschaftigt  sich  mit  Realtime  Networking  in  Wireless  and  Wired  Networks. 
Dabei  sollte  untersucht  werden,  in  wie  weit  sich  diese  beiden  Netzwerktechniken  fur  Soft- 
und  Hardrealtime  Anforderungen  eignen.  Beriicksichtigt  wurden  insbesondere  die  Schicht 
2  des  O SI/ISO  Ref erenzmodells,  da  das  Mediumzugriffsverfahren  die  Eigenschaften  im 
Hinblick  auf  Reaktionszeit,  sowie  Garantien  fur  die  Zuteilung  des  Mediums  bestimmen. 
Ein  weiteren  Schwerpunkt  stellen  die  Realtime  Protokolle  der  Schicht  4  da.  Dort  wurde 
insbesondere  die  Tauglichkeit  fur  Wireless  LANs  betrachtet. 
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3.1  Einleitung 


Die  moderne  Kommunikationsindustrie  setzt  aus  Kosten-  und  Leistungsgriinden  fur  die 
Zukunft  verstarkt  auf  Video-  und  Voice  over  IP  Losungen  [1],  Dabei  kommen  im  Home- 
und  Officebereich  kabellose  und  Kabelnetzwerke  zum  Einsatz.  Allerdings  mochte  der  Kun- 
de,  wie  beim  herkommlichen  Telefonieren,  einen  Qualitats-  und  Verfiigbarkeitsstandard. 
Dariiber  hinaus  gibt  es  aber  auch  Industrieanwendungen:  So  werden  Fertigungsanlagen 
und  Roboter  liber  Realtimeapplikationen  gesteuert.  Benotigen  Steuerungsbefehle  zu  lange 
Zeit,  kann  es  zu  Fehlproduktionen  oder  gar  teuren  Beschadigungen  kommen. 

Aber  auch  in  weitaus  kritischeren  Bereichen  werden  Echtzeitanwendungen  eingesetzt:  So 
muss  die  rechtzeitige  .Abschaltung  eines  Kernkraftwerks  gewahrleistet  werden.  Bei  der 
Flugbahnberechnung  einer  Tragerrakete  wird  die  Absprengung  der  Zusatztanks  ebenfalls 
exakt  geplant.  Kommt  es  bei  der  Ubertragung  der  entsprechenden  Befehle  vom  Zentral- 
computer  zu  den  jeweiligen  Steuereinheiten  zu  Verzogerungen,  bedeutet  das  den  Verlust 
der  Rakete  samt  Ladung,  was  einen  wirtschaftlichen  Schaden  von  mehreren  hundert  Mil- 
lionen  Euro  zur  Folge  hat  [2]. 

Aber  nicht  nur  im  zivilen  Umfeld  spielen  Realtime  Netzwerke  eine  Rolle:  Aufklarungs- 
drohen  erhalten  per  Funksignalen  ihre  Steuerungsbefehle.  Gleichzietig  senden  sie  Video-, 
Infrarot-  und  GPS  Informationen  an  die  zugehorige  Bodenstation.  Von  dort  aus  werden 
sie  in  Echtzeit  an  Kampfeinheiten  im  Einsatzgebiet  weitergeleitet.  Erreichen  dabei  In¬ 
formationen  zu  spat,  oder  gar  fehlerhaft  den  Empfanger,  gehen  die  Konsequenzen  von 
Eigenverlusten  bis  zu  hohen  Kolatteralschaden  [3]. 


3.1.1  Unterschied  zwischen  Wireless  und  Wired  Networks 

Um  die  beiden  Netzwerktechniken  untersuchen  zu  kdnnen,  betrachtet  man  erstmal  die 
Unterschiede  bzw.  die  Vor-  und  Nachteile.  Wahrend  Kabelnetzwerke  in  der  Regel  Kupfer- 
oder  Glasfaserkabel  als  Ubertragungsmedium  nutzen,  werden  im  Wireless  LAN  die  Bits 
mittels  elektromagnetischer  Wellen  fiber  den  Ather  verschickt.  Das  bewerkstelligt  auch 
den  grofien  Vorteil  der  WLANs,  dass  die  User  innerhalb  eines  Hotspots  vollige  Bewe- 
gungsfreiheit  haben.  Kabelnetzwerke  verfiigen  nur  fiber  den  beschrankten  Raum,  den  die 
Kabellange  zulasst,  wobei  hier  auch  noch  darauf  geachtet  werden  muss,  dass  man  Kabel 
nicht  einfach  quer  durch  den  Raum  legen  kann. 

Das  fuhrt  gleich  dazu,  dass  man  Unterschiede  in  der  Topologie  feststellen  kann:  Wahrend 
die  Anordnung  der  Mitglieder  eines  WLANs  vollig  beliebig  ist,  sind  Kabelnetze  an  eine 
Baum-,  Ring-  oder  Linienstruktur  gebunden. 

Inwieweit  sich  Netzwerktechniken  durchsetzen  beruht  insbesondere  auf  dem  Kostenfaktor: 
WLAN  Adapterkarten  kosten  um  die  40,-  Euro  und  die  benotigten  Accesspoints  um  die 
100,-  Euro.  Kupfergebundene  Losungen  liegen  mit  10,-  Euro  fur  die  Netzwerkkarte  und 
30,-  Euro  fur  einen  Hub  da  deutlich  gunstiger. 
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Zumal  sie  mit  bis  zu  1000  Mbit  im  Gegensatz  zu  54  Mbit  von  Wireless  LANs  eine  deutlich 
groBere  Bandbreite  bieten.  Allerdings  kann  das  Kabelverlegen  auf  grofieren  Strecken  oder 
wegen  baulichen  Mafinahmen  den  Kostenpunkt  von  Kabelnetzwerken  in  die  H5he  treiben. 

Ein  weiterer  Schwachpunkt  von  WLANs  ist  der  hohe  Aufwand,  die  Ubertragungen  abzusi- 
chern.  Bei  Kabelnetzwerken  muss  eine  direkte  Verbindung  bestehen,  um  den  Datenverkehr 
abzuhoren  oder  zu  beeinflussen.  Bei  WLANs  reicht  es  jedoch,  sich  innerhalb  des  Sende- 
bereichs  eines  Hotspots  mit  einer  entsprechenden  Adapter karte  aufzuhalten. 

WLANs  bieten  durch  ihre  Flexibelitat  einen  Vorteil:  Ist  die  Hardware  richtig  konfiguriert, 
so  kann  man  das  Netzwerk  abbauen,  und  ohne  grofieren  Aufwand  an  einem  anderen  Ort 
wieder  in  Betrieb  nehmen,  vorausgesetzt,  dort  gibt  es  keine  Storquellen. 


3.1.2  Definition  Soft-  und  Hardrealtime 

Bevor  man  die  Echtzeiteigenschaften  der  beiden  Netzwerktechniken  untersucht,  muss  erst- 
mal  der  Begriff  Realtime  geklart  werden:  Generell  gilt,  es  wird  ein  Zeitpunkt  tmin  und  ein 
Zeitpunkt  tmax  festgelegt.  Innerhalb  dieses  Zeitraumes  sollten  die  Daten  eintreffen.  Dabei 
unterscheidet  man  aber  zwei  Kategorien:  weiche  (Soft)  und  harte  (Hard)  Echtzeitbedin- 
gungen.  Wahrend  fur  weiche  Echtzeitbedingungen  die  Grenzen  tmin  und  tmax  eher  die 
optimale  Zeitspanne  bestimmen,  miissen  bei  harten  Echtzeitappliaktionen  die  Grenzen 
streng  eingehalten  werden,  und  diirfen  weder  unter-  noch  iiberschritten  werden.  Das  Gan- 
ze  lasst  sich  durch  folgende  Grafik  veranschaulichen  3.1: 


Vo 


Abbildung  3.1:  Soft-  und  Hardrealtime  im  Vergleich 

Ein  nicht  Einhalten  der  Zeitspanne  fiihrt  bei  Softrealtime  in  der  Regel  zur  Minderung  der 
Ubertragungsqualitat.  Bei  Hardrealtime  hingegen  fiihrt  ein  Verletzen  der  Zeitpunkte  zur 
Zerstorung  des  Systems  und  wird  somit  nicht  toleriert. 
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Anwendungsbeispiele  fur  Softrealtime  sind  Bild-  und  Sprachiibertragung,  Videostreaming, 
Computerspiele,  usw.  Um  die  Ubertragungsqualitat  zu  erhohen,  verwenden  die  Applika- 
tionen  kleine  Zwischenspeicher.  Dadurch  konnen  kleinere  Unregelmafiigkeiten  aufgefangen 
werden.  Beispiele  fiir  Hardrealtime  Systeme  sind  Anwendungen  in  der  Raumfahrt,  Steue- 
rung  von  Kraftwerken  und  Industrieanlagen. 


3.1.3  Deis  idealisierte  Echtzeitnetzwerk 

Nachdem  der  Begriff  Realtime  geklart  wurde,  kann  man  ein  idealisiertes  Netzwerk  fiir 
Realtimeumgebungen  aufstellen: 

Reaktionszeit:  Mochte  eine  Station  ein  Paket  senden,  sollte  das  Medium  sofort  zur 
Verfiigung  stehen.  Dies  ist  aber  in  einem  herkommlichen  Netzwerk  nicht  immer  moglich. 
Daher  sollte  zumindest  eine  maximale  Zeit  feststehen,  in  der  auf  das  Medium  zugegriffen 
werden  kann. 

Bandbreite:  Gute  Video-  und  Audiosignale  benotigen  immer  mehr  Bandbreite.  Daher 
ware  eine  unbegrenzte  Bandbreite  wiinschenswert,  aber  nicht  realisierbar.  Daher  sollte 
zumindest  geniigend  Banbreite  zur  Verfiigung  stehen,  um  alle  Teilnehmer  mit  der  ge- 
wiinschten  Qualitat  versorgen  zu  konnen. 

Garantien:  Fiir  harte  Echtzeitapplikation  gelten  sehr  strenge  Zeitintervalle.  Das  idea¬ 
lisierte  Netzwerk  kann  diese  Zeitpunkte  natiirlich  nicht  exakt  erreichen.  Daher  werden 
zumindest  Garantien  iiber  kleine  Zeitfenster  gefordert  und  insbesondere  Zeitpunktober- 
grenzen,  die  nie  iiberschritten  werden. 

Signalausbreitung:  Beginnt  eine  Station  zu  senden,  sollte  der  Empfanger  ohne  Zeitver- 
zug  die  Informationen  empfangen.  Dies  ist  aber  gerade  bei  grofieren  Entfernungen  nicht 
moglich,  da  sich  die  Signale  maximal  mit  Lichtgeschwindigkeit  c  ausbreiten.  Des  weiteren 
werden  gerade  in  Wide  Area  Networks  (WANS)  Komponenten  wie  Router  und  Switches 
benotigt,  die  die  Pakete  kurz  zwischenspeichern.  Zusatzlich  bestehen  bei  WANS  mehre- 
re  Moglichkeiten  ein  Paket  von  Station  A  zur  Station  B  zu  transportieren.  Daher  sollte 
immer  der  schnellste  Weg  zwischen  zwei  Punkten  gewahlt  werden. 

MAC  Frames:  Im  idealen  Netzwerk  sollten  nahezu  nur  Nutzdaten  iibertragen  werden. 
Da  aber  fiir  die  einzelnen  Schichten  des  ISO/OSI  Referenzmodells  zusatzliche  Informatio¬ 
nen  benotigt  werden,  miissen  die  zusatzlichen  Informationen  der  MAC  Frames  moglichst 
gering  ausfallen. 

Datengiiltigkeit:  Gerade  fiir  harte  Realzeitsysteme  ist  eine  Vorraussetzung,  dass  die 
empfangenen  Informationen  korrekt  sind.  Es  darf  zwischen  den  Stationen  nicht  zu  Uber- 
tragungsfehlern  kommen.  Falls  doch  muss  zumindest  gewahrleistet  sein,  dass  Fehler  er- 
kannt  und  eventuell  sogar  beseitigt  werden  konnen. 
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3.1.4  Das  OSI/ISO  Referenzmodell 

Diese  Arbeit  untersueht  beide  Netzwerktechniken  insbesondere  im  Hinblick  auf  die  Schicht 
2,  MAC  Layer,  und  Schicht  4,  Transport  Layer.  Die  Bitiibertragungsschicht  hat  im  Hin¬ 
blick  auf  Realtime  Eigenschaften  keine  groBe  Bedeutung.  Die  Einordnung  kann  man  in 
der  Grafik  3.2  sehen. 


Schicht  7 
■ 

Application  Layer  /  Anwendungschicht 

V  ■  ;> v i  ^ :  5 SS :  1 

Schicht  4 

Transport  Layer  /  Transportschicht 

- 

A 

Schicht  2 

Data  Link  Layer  /  Sicherungsschicht 

|  : ,!l  V.  J v / :  .  . '  hj 

Abbildung  3.2:  Einordnung  der  zu  untersuchenden  Schichten 


I 

3.2  Die  Netzwerktechniken  im  Vergleich  (Schicht  2) 

3.2.1  Allgemeine  Multiplexverfahren 

Mochten  mehrere  Stationen  liber  dasselbe  Medium  Informationen  iibertragen,  mlissen 
Verfahren  zur  Verteilung  des  Mediums  benutzt  werden.  In  diesem  Abschnitt  werden  die 
sogenannten  Multiplexverfahren  untersueht,  insbesondere  auf  ihre  Vor-  und  Nachteile  fur 
Echtzeitumgebungen.  Dabei  gilt  als  Anmerkung,  dass  die  einzelnen  Verfahren  beliebig 
miteinander  kombinierbar  sind. 


Space  Division  Multiplex  (SDM) 

Dabei  wird  das  Medium  durch  eine  raumliche  Unterteilung  aufgeteilt,  so  dass  sich  die 
Stationen  nicht  gegenseitig  storen.  Beim  Einsatz  von  normalen  Antennen  bietet  SDM  die 
voile  Bandbreite,  allerdings  nur  fur  zwei  Teilnehmer.  Optimieren  kann  man  die  Teilneh- 
meranzahl  durch  den  Einsatz  von  Richt antennen.  Dadurch  wird  allerdings  die  Mobilitat 
der  Stationen  stark  eingeschrankt.  Aufierdem  steigen  dadurch  die  Kosten,  da  fur  jede 
benotigte  Verbindung  zwei  Antennen  vorhanden  sein  miissen  [7]. 
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Time  Division  Multiplex  (TDM) 

Bei  TDM  wird  das' Medium  nacheinander  den  einzelnen  Stationen  zugeteilt.  Dies  kann 
durch  eine  feste  Vergabestrategie  erfolgen,  was  aber  einen  Synchronisationsmechanismus 
voraus  setzt.  Oder  es  wird  ein  dynamisches  Vergabesystem  verwendet,  bei  dem  nur  Sta¬ 
tionen,  die  auch  senden  wollen,  sich  um  das  Medium  bemiihen.  TDM  bietet  zwar  die  Mog- 
lichkeit,  beliebig  viele  Teilnehmer  zu  verwenden,  allerdings  kostet  jeder  weitere  Teilnehmer 
Bandbreite.  Schwerwiegender  sind  aber  die  Einschrankungen  durch  Kollisionsvermeidun- 
gen  und  Synchronisierungsalgorithmen.  Hinzu  kommt,  dass  es  bei  vielen  Teilnehmern  zu 
Beeintrachtigungen  der  Reaktionszeit  der  einzelnen  Stationen  kommen  kann  [7]. 

Frequency  Division.  Multiplex  (FDM) 

FDM  unterteilt  das  Frequenzband  in  verschiedene  Kanale.  Dies  bietet  unter  der  Vor- 
aussetzung,  dass  die  Teilnehmerzahl  x  kleiner  gleich  der  Anzahl  der  Kanale  k  liegt,  und 
die  Bandbreite  der  Kanale  ausreichend  groB  ist,  gute  Bedingungen  fur  Realzeitsysteme. 
Sind  diese  Voraussetzungen  nicht  gegeben,  muss  FDM  mit  einem  der  anderen  Multiplex- 
verfahren  kombiniert  werden,  was  zur  Folge  hat,  dass  deren  schlechte  Eigenschaften  mit 
iibernommen  werden  [7]. 

Code  Division  Multiplex  (CDM) 

Bei  CDM  werden  die  Signale  mittels  eines  Codierungsverfahrens  verandert,  so  dass  selbst 
nach  Uberlagerungen  und  kleinen  Storungen  die  Daten  vom  Empfanger  gelesen  werden 
konnen.  Dies  geht  aber  zu  Lasten  der  Reaktionszeit  und  erzeugt  eine  hohere  Komplexitat: 
Der  En-  und  Decodiervorgang  benotigt  zusatzlich  Zeit  und  die  Stationen  miissen  ihre 
Sendestarke  kontrollieren,  um  kein  anderes  Signal  zu  iibertonen.  Bei  einer  sehr  groBen 
Teilnehmerzahl  bietet  CDM  die  einzige  effektive  Losung,  deswegen  wird  es  dort  auch  bei 
Realtime  Anwendunge'n  eingesetzt  (Bsp.  UMTS)  [7]. 


3.2.2  Vergleich  der  MAC  Frames 

Bevor  die  Zugriffsverfahren  untersucht  werden,  werden  die  MAC  Frames  miteinander  ver- 
glichen,  um  festzustellen,  ob  es  auch  dort  Unterschiede  gibt.  Auch  das  Verhaltnis  der 
Zusatzinformationen  zur  Nutzlast  ist  fur  Echtzeitapplikationen  interessant.  Als  Vertreter 
fur  die  Kabelnetzwerke  wird  Ethernet  802.2  verwendet.  WLAN  nach  802.11  steht  fur  die 
kabellosen  Varianten. 


IEEE  802.3  MAC  Frame 

Der  Frame  (siehe  Abb.  3.3)  besteht  aus  sechs  Feldern.  Dabei  nimmt  der  Header  19  Byte 
in  Anspruch  und  gliedert  sich  in  die  Felder  Preamble,  Start  Frame  Delimiter  (SFD),  Des¬ 
tination  und  Source  Adress.  Jeder  802.3  Frame  beginnt  mit  einer  Folge  von  Ein  sen  und 
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Figure  5-3  Bhernet  and  IEEE  802.3  Frame  Formats 
Abbildung  3.3:  Der  802.3  MAC  Frame 


Nullen  im  Preamble  Feld.  Dies  dient  dazu,  anderen  Stationen  mitzuteilen,  dass  ein  Fra¬ 
me  unterwegs  ist.  Aufierdem  gibt  es  den  anderen  Stationen  Zeit,  sich  auf  die  Bitfolge  zu 
synchronisieren.  Das  Feld  SFD  signalisiert  den  Beginn  der  Ziel  Adresse.  In  den  beiden 
Adressfeldern  steht  jeweils  eine  6  Byte  lange  MAC  Adresse.  Danach  kommt  der  variable 
Payload  von  46  bis  1500  Byte.  Das  Feld  FCS  enthalt  zum  Schluss  noch  eine  CRC  Priif- 
summe,  mit  deren  Hilfe  beschadugte  Frames  erkannt  werden  konnen.  Insgesamt  besteht 
der  Frame  aus  24  Byte  ohne  das  Payloadfeld. 


IEEE  802.11  MAC  Frame 

Beim  802.11  MAC  Frame  3.4  existieren  insgesamt  neun  Felder.  Der  Header  allein  enthalt 
bereits  sieben  Felder.  Das  Feld  Frame  Control  FC  enthalt  WLAN  spezifische  Informa- 
tionen,  wie  zum  Beispiel:  Versionsnummer,  WEP,  Power  Management.  Im  Feld  Duration 
ID  wird  die  Dauer  der  Ubertragung  angeben.  Die  ersten  drei  Adressen  enthalten  neben 
der  Quell-  und  Zieladresse  auch  noch  den  Basis  Service  Set  Identifyer.  Das  Feld  Sequence 
Control  dient  zur  Einordnung  des  Frames.  Nur  bei  Kommunikation  zwischen  zwei  verteil- 
ten  Systemen  wird  auch  das  vierte  Adressfeld  genutzt.  Wie  bei  Ethernet  enthalt  das  Feld 
FCS  eine  Prufsumme  zur  Fehlererkennung. 


3.2.3  MEDIA  ACCESS  CONTROL  Protokolle  in  Ethernet  Ka- 
belnetzwerken 


Das  IEEE  hat  fiir  Ethernet  Netzwerke  drei  MAC  Verfahren  aufgestellt:  TokenRing  (802.5), 
TokenBus  (802.4)  und  CSMA/CD  (802.3).  Alle  drei  Verfahren  werden  im  folgenden  Ab- 
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Abbildung  3.4:  Der  802.11  MAC  Frame 


schnitt  untersucht,  wobei  802.3  heutzutage  den  mit  Abstand  grofiten  Marktanteil  stellt. 

IEEE  802.5  Token  Ring 

Token  Ring  wurde  urspriinglich  von  IBM  entwickelt  und  erst  spater  vom  IEEE  als  Stan¬ 
dard  verabschiedet.  Dabei  bilden  alle  Teilnehmer  einen  geschlossen  Ring.  Die  Ubertra- 
gungsgeschwindigkeit  betragt  4  oder  16  MBit/s.  Dabei  lassen  sich  bis  zu  260  bzw.  72  (bei 
16  MBit/s)  Teilnehmer  anschliefien. 

Mochte  ein  Teilnehmer  Daten  libertragen,  muss  er  auf  die  Zuteilung  des  Tokens  (spez. 
Bitmuster)  warten.  Erreicht  ihn  das  Token,  so  kann  er  mit  der  Dateniibertragung  beginnen 
und  ein  Frame  libertragen.  Dabei  werden  die  Daten  von  einem  Teilnehmer  zum  nachsten 
immer  in  der  gleichen  Richtung  weitergeleitet.  Erreicht  den  Sender  der  eigene  Frame 
wieder,  so  erzeugt  er  das  Token  und  sendet  es  weiter. 

Das  Verfahren  (siehe  Abb.  3.5)  lasst  sich  mit  Polling  Mechanismen  vergleichen,  nur  das 
bei  Token  Ring  die  Anordnung  der  Teilnehmer  den  Master  ersetzt.  Allerdings  hangt  der 
Zeitpunkt  der  erneuten  Zuteilung  von  der  Anzahl  der  sendewilligen  Stationen  ab  [4]. 


IEEE  802.4  Token  Bus 


Zu  Beginn  muss  man  sagen,  dass  die  IEEE  den  Standard  802.4  zuriickgenommen  hat. 
Beim  Token  Bus  hangen  die  Teilnehmer  an  einer  Leitung,  die  im  Gegensatz  zum  Token 
Ring  nicht  geschlossen  ist.  Allerdings  wird  iiber  diese  Topologie  ein  logischer  Ring  gelegt. 
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Abbildung  3.5:  Das  Verfahren  im  Uberblick  [4] 


Jede  Station  kennt  die  Adresse  der  nachfolgenden  Station:  Es  entsteht  ein  geschlossener 
Ring,  da  die  letzte  Station  als  Nachfolger  die  erste  Station  hat. 

Irrf  Gegensatz  zum  Token  Ring  bekommt  jede  Station  einen  festen  Zeitintervall  zur  Uber¬ 
tragung.  Somit  kann  ein  Zeitpunkt  tmax  garantiert  werden,  zu  dem  eine  Station  spatestens 
wieder  senden  kann.  Dies  ist  im  Hinblick  auf  harte  Realzeitsysteme  interessant:  Liegt  tmax 
der  erneuten  Token  Zuteilung  soweit  unterhalb  von  tmax  der  Echtzeitapplikation,  dass  die 
Datenmenge  rechtzeitig  iibertragen  werden  kann,  bietet  Token  Bus  Einsatzmoglichkeiten 
fur  Echtzeitapplikationen.  ' 

Dies  zeigt  sich  auch  daran,  dass  Token  Bus  von  General  Motors  in  der  Steuerung  von 
Produktionsanlagen  eingesetzt  wurde.  Aufierdem  kennt  Token  Bus  eine  Prioritatseintei- 
lung:  Wichtige  Stationen  konnen  im  logischen  Ring  bei  einer  Runde  mehnnals  das  Token 
erhalten. 

Die  Ubertragungsgeschwindigkeit  liegt  bei  1,  5  oder  10  MBit/s. 

Diese  Methode  eignet  sich  auch  fur  andere,  nicht  geschlossene  Topologien:  Es  kann  jeder- 
zeit  ein  logischer  Ring  aller  Teilnehmer  gebildet  werden  [5] . 


IEEE  802.3  Carrier  Sense  Multiple  Access  with  Collision  Detection  (CSMA/CD) 


CSMA/CD  ist  heute  der  weit  verbreiteste  Standard  in  Ethernet  Netzwerken.  Die  Teilneh¬ 
mer  werden  in  einer  Baumstruktur  miteinander  verbunden.  Mochte  eine  Station  Daten 
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senden,  iiberpriift  sie  das  Medium:  1st  die  Leitung  frei,  wartet  sie  noch  mal  den  Interframe 
Gap  ab,  bevor  sie  erneut  iiberpruft,  ob  noch  immer  eine  Ubertragung  moglich  ist.  Falls  ja, 
beginnt  sie  mit  der  Ubertragung.  Gleichzeitig  hort  sie  aber  die  Leitung  ab,  um  Kollisionen, 
die  durch  gleichzeitiges  Beginnen  einer  Ubertragung  oder  durch  lange  Kabelverbindungen 
entstehen,  zu  erkennen.  Erkennt  eine  Station  eine  Kollision,  bricht  sie  die  Ubertragung 
ab,  und  sendet  stattdessen  ein  Jaming  Signal.  Danach  greift  ein  Backoff  Algorithmus, 
der  verhindern  soli,  dass  beide  Stationen  wieder  zur  gleichen  Zeit  mit  der  Ubertragung 
beginnen. 

Bei  zwei  Rechnern  und  voll  Duplexfahigen  Netzwerkkarten  ist  CSMA/CD  ohne  Einschran- 
kungen  hart  echtzeitfahig.  Erst  bei  mehreren  Rechnern  konnen  Probleme  durch  Kollisio¬ 
nen  auftreten.  Dies  kann  allerdings  umgangen  werden,  durch  den  Einsatz  intelligenter 
Switches,  statt  der  herkommlichen  Hubs:  Die  Switches  erkennen  die  Ziel  MAC-Adresse 
eines  Pakets,  und  leiten  es  nur  noch  an  den  betroffenen  Rechner  weiter.  Dies  wird  durch 
kleine  Puffer  erreicht,  in  denen  die  Pakete  zwischengespeichert  und  ausgewertet  werden. 
Dieser  Vorgang  kostet  allerdings  Zeit  und  fiihrt  zu  einem  neuen  Problem:  Ist  der  Speicher 
voll,  werden  keine  neuen  Pakete  angenommen.  Es  kommt  zu  Paketverlusten. 

IEEE  802.3  kann  mittlerweile  mit  bis  zu  1000  MBit/s  als  Bandbreite  betrieben  werden 

[6], 

3.2.4  MEDIA  ACCESS  CONTROL  Protokolle  in  Funknetzwer- 
ken 

Zusatzlich  zum  Problem,  den  Zugriff  auf  das  gemeinsame  Medium  zu  regeln,  kommen  spe- 
zifische  Probleme  der  Funknetzwerke  hinzu.  Wahrend  bei  Kabelnetzwerken  alle  Teilneh- 
mer  bekannt  sind,  ist  das  bei  Funknetzwerken  nicht  gewahrleistet.  Dies  fiihrt  zu  folgenden 
Schwierigkeiten: 

Ein  Problem,  dass  daraus  resultiert,  ist  das  sogenannte  Hidden  Station  Problem:  Mochte 
eine  Station  A  der  Station  B  Daten  senden,  hort  es  das  Medium  ab.  Dabei  kann  es  aber  auf 
Grund  der  raumlichen  Ausdehnung  nicht  horen,  dass  eine  Station  C  (die  Hidden  Station) 
bereits  begonnen  hat,  Daten  zur  Station  B  zu  senden.  Also  fangt  auch  A  an,  Informationen 
zu  iibertragen:  Bei  der  Station  B  werden  die  Informationen  durch  die  Uberlagerung  der 
Signale  zerstort  (siehe  Abb.  3.6). 


ABC 

Abbildung  3.6:  Das  Hidden  Station  Problem  [7] 

Ein  weiteres  Problem  schrankt  die  Effektivitat  von  Funknetzwerken  ein.  Eine  Station  A 
mochte  Informationen  zur  Station  D  senden.  Bei  der  Uberpriifung  des  Mediums  stellt  sie 
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fest,  dass  bereits  die  Nachbarstation  B  Daten  zur  Station  C  tibertragt.  Dabei  liegen  die  Sa- 
tionen  soweit  auseinander,  dass  eine  Ubertragung  von  A  nach  D  problemlos  moglich  ware: 
Die  Station  A  ist  der  Station  B  „ausgeliefert“.  Das  Problem  heiht  Exposed  Terminal. 


(Slotted)  Aloha 


Aloha  ist  ein  zufalliges  TDM-Verfahren.  Es  wurde  erstmals  in  einem  Forschungsnetz  der 
Universitat  von  Hawaii  verwendet.  Eine  Station,  die  Daten  senden  mochte,  versucht  dies 
einfach,  in  der  Hoffnung,  das  Medium  ist  frei,  und  der  Empfanger  erhalt  die  Daten.  Gliickt 
dieser  Versuch,  erhalt  der  Sender  eine  Quittung  des  Empf angers. 

Da  dieser  Vorgang  aber  nicht  zentral  gesteuert  wird,  ist  die  Wahrscheinlichkeit  sehr  hoch, 
dass  auf  Grund  anderer  sendender  Stationen  es  haufig  zu  Kollisionen  kommt.  Der  Emp¬ 
fanger  kann  keine  Daten  mehr  aus  dem  empfangen  Signal  entnehmen.  Des  weiteren  kann 
es  zum  Einen  passieren,  dass  eine  Station  so  ungiinstig  den  Ubertragungszeitraum  wahlt, 

'  dass  sie  sowohl  das  Ende  einer  fast  fertigen  Ubertragung,  als  auch  den  Anfang  einer  neuen 
Ubertragung  iiberlagert.  Dadurch  sind  alle  drei  Ubertragungen  nicht  erfolgreich. 

Um  das  zu  verhindern,  wurden  spater  feste  Zeitschlitze(sog.  Slots)  eingefiihrt,  in  denen 
eine  Station  senden  darf.  Daher  auch  der  Name  der  Erweiterung:  Slotted  Aloha. 

Da  Aloha  ursprunglich  mit  nur  drei  Station  betrieben  wurde,  bestand  keine  Notwendigkeit, 
dip  Probleme  von  Hidden  Station  und  Exposed  Terminal  zu  behandeln. 

Insgesamt  haben  Aloha  und  Slotted  Aloha  bei  einem  Poissonverteilten  Datenaufkommen 
jedoch  nur  eine  Wirksamkeit  von  16  Prozent  (bzw.  32  Prozent).  Da  Kollisionen  sowohl 
beim  Senden  der  Daten  als  auch  beim  Verschicken  der  Empfangsquittung  entstehen  kon- 
nen,  ist  (Slotted)  Aloha  denkbar  ungeeignet  fur  Realtime  Applikationen  (Abb.  3.7)  [7]. 

Aloha  . . . 

r 

Sender  A  — L 
Sender  B  — 

Sender  C  — 

Slotted  Aloha 


Sender  A 
Sender  B 
Sender  C 


Abbildung  3.7:  Schema  von  Aloha,  bzw.  Slotted  Aloha  [7] 
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Demand  Assigned  Multiple  Access  (DAMA) 

Um  der  schlechten  Ausnutzung  von  (Slotted)  Aloha  zu  begegnen,  wurde  DAMA  entwi- 
ckelt.  Dabei  werden  vor  Beginn  des  Ubertragungszeitraums  spatere  Timeslots  reserviert. 
Die  Reservierung  erfolgt  entweder  mittels  Slotted  Aloha  oder  eines  festen  Zeitmultiplex. 

Bei  der  Slotted  Alhoa  Version  nimmt  man  in  Kauf,  d,ass  es  zu  Kollisionen  kommt.  Dafiir  ist 
dort  eine  dynamische  Teilnehmerzahl  moglich.  Bei  einem  festen  Zeitmultiplex  hingegen, 
muss  entweder  die  max.  Teilnehmerzahl  bekannt  sein,  oder  es  gibt  eine  zentrale  Station, 
die  den  Zeitmultiplex  entsprechend  der  aktuellen  Teilnehmerzahl  anpasst. 

Das  Problem  ist,  dass  dafiir  zum  einen  ein  Synchronisierungsmechanismus  notig  ist,  zum 
anderen  muss  jeder  Teilnehmer  eine  Reservierungsliste  fuhren.  Fur  Realtimeanwendungen 
mit  sehr  kleinem  tmax  kommt  hinzu,  dass  der  Reservierungsvorgang  unnotig  Zeit  kostet 
[7],  .  , 


Aloha  Reserved  Aloha  Reserved  Aloha  Reserved  Aloha 


Abbildung  3.8:  DAMA  mit  Slotted  Aloha  zur  Reservierung  [7] 


N  Mlnischlitze 


N  *  k  Datenschlitze 
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Abbildung  3.9:  DAMA  mit  implizierter  Reservierung  [7] 


Polling 

Beim  Polling  kann  eine  Station,  der  Master,  alle  anderen  Stationen  erreichen.  Dies  bedeu- 
tet  insbesondere,  es  existiert  kein  Hidden  Terminal.  Dann  gibt  es  verschiedene  Moglich- 
keiten,  dass  Medium  aufzuteilen:  Es  gibt  einen  festen  Zeitmultiplex,  bei  dem  der  Master 
den  einzelnen  Slaves  nach  und  nach  Zugriff  aufs  Medium  gewahrt,  indem  er  sie  zum  Sen- 
den  auffordert.  Der  grofie  Vorteil  besteht  darin,  dass  es  ,solange  es  zu  keinen  Storungen 
von  Aufien  kommt,  Kollisionen  vermieden  werden  konnen.  Des  weiteren  kann  man  sogar 
Garantien  abgeben,  nach  welcher  Zeit  eine  Station  wieder  senden  kann. 

Eine  weitere  Moglichkeit  ist,  dass  nach  einem  Startping  alle  sendewilligen  Stationen,  mit¬ 
tels  FDM  oder  CDM  gleichzeitig  eine  Zufallszahl  iibertragen.  Die  Slaves  werden  dann 
chronologisch  ihrer  Zufallszahl  nacheinander  abgearbeitet.  Allerdings  kann  es  dabei  zu 
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Kollisionen  kommen.  Dadurch  verliert  aber  das  Polling  seinen  Vorteil  gegeniiber  anderen 
Verfahren. 

Durch  die  Vorraussetzung,  dass  eine  Station  bereits  alle  Stationen  erreichen  kann  und  sie 
selber  an  die  anderen  Stationen  die  Sendeberechtigung  verteilt,  kann  weder  das  Hidden 
Station  Problem  noch  ein  Exposed  Terminal  auftreten.  Damit  bietet  Polling  eine  Mog- 
lichkeit  fur  eine  begrenzte,  und  bekannte  Teiinehmerzahl  echtzeitigfahig  zu  sein  [7]. 


Multiple  Access  with  Collision  Avoidance  (MACA) 

Eine  Variante  (Carrier  Sense  Multiple  Access  with  Collision  Avoidance,  kurz  CSMA/CA) 
des  MACA  ist  zur  Zeit  das  gangigste  Verfahren  fur  WLANs,  denn  sie  wird  vom  IEEE 
Standard  802.11  verwendet.  Dabei  verwenden  alle  Stationen  kurze  Signalisierungsmittei- 
lungen  (RTS)  um  den  anderen  Stationen  den  Sendewunsch  mitzuteilen,  wahrenddessen 
warten  sie  auf  Riickmeldungen  (CTS)  des  Empfangers,  ob  er  iiberhaupt  empfangsbereit 
ist. 

Die  Mitteilungen  enthalten  neben  der  Ziel-  und  der  Quelladresse  noch  die  Paketlange, 
damit  die  Ubertragungsdauer  abgeschatzt  werden  kann.  Dadurch  werden  Probleme,  wie 
das  Hidden  und  Exposed  Terminal,  umgangen.  Um  Kollisionen  bei  den  Mitteilungen  zu 
vermeiden,  werden  Interframe  Spaces  (IFS)  in  Verbindung  mit  einem  zufalligen  Backoff 
Mechanismus  in  einem  Wettbewerbsfenster  zwischen  den  einzelnen  Ubertragungen  ver¬ 
wendet.  Dabei  werden  drei  Arten  von  Abstanden  unterschieden: 

Short  IFS  Muss  eine  Station  auf  eine  Signalisierungsmitteilungen  antworten,  wartet  sie 
nur  einen  kurzen  Zeitpunkt  ab,  damit  keine  andere  Ubertragung  vorher  beginnen  kann. 

PIFS  Mochte  eine  Station  Ubertragungen  mit  hoherer  Prioritat  versenden,  wartet  sie 
einen  Zeitraum  ab,  der  langer  als  der  Short  IFS  ist,  aber  noch  vor  den  normalen  Ubertra¬ 
gungen  liegt.  Beispiele  hierfiir  sind  Realtime  Daten. 

DIFS  Fur  die  normale  Dateniibertragung  wird  am  langsten  gewartet,  damit  unwichtige 
Ubertragungen  nicht  unnotig  das  Netzwerk  blockieren. 

Der  Backoff  Mechanismus  dient  dazu,  dass  nicht  alle  sendewilligen  Stationen  gleichzeitig 
nach  Abwarten  des  DIFS  zu  Senden  beginnen.  Jede  Station  ermittelt  eine  Zufallszahl, 
die  sie  zusatzlich  nach  dem  DIFS  wartet.  Dabei  hort  sie  nebenbei  das  Medium  ab,  um 
festzustellen,  ob  eine  andere  Station  mit  einer  niedrigeren  Zufallszahl  schon  zu  senden 
begonnen  hat.  Bei  gleicher  Zufallszahl  kann  es  natiirlich  zu  Kollisionen  kommen. 

Als  Realtimeumgebung  bietet  es  statistisch  gesehen  eine  relativ  gute  Vorraussetzung  fur 
weiche  Echtzeit  Applikationen,  obwohl  natiirlich  die  Signalisierungsmitteilungen  und  das 
Wettbewerbsfenster  fur  Verzogerungen  und  Overhead  sorgen.  Mit  steigender  Teiinehmer¬ 
zahl  sinkt  allerdings  die  Qualitat  erheblich.  Fur  harte  Echtzeitbedingungen  bietet  MACA 
keine  Moglichkeit,  da  ein  erfolgreicher  Mediumzugriff  in  einer  bestimmten  Zeit  nicht  fest- 
gelegt  werden  kann  [7]. 
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Abbildung  3.10:  Die  unterschiedlichen  IFS  bei  MACA  [7] 


3.2.5  Zusammenfassung  der  Mediumzugriffsverfahren 


Bei  Kabelnetzwerken  und  Hardrealtimeanwendungen  bieten  die  Token  Systeme,  insbe- 
sondere  Token  Bus  gute  Voraussetzungen.  Durch  den  logischen  Ring  konnen  Garantien 
fur  den  spatesten  Zeitpunkt  des  erneuten  Mediumzugriffs  abgegeben  werden.  Allerdings 
nimmt  man  dafiir  eine  aufwendige  Verwaltung  bei  Neuaufnahmen  von  Ringmitgliedern  in 
Kauf. 


Mochte  man  bei  harten  Echtzeitapplikationen  CSMA/CD  verwenden,  sollte  man  auf  die 
Umgebung  Wert  legen:  Unnotige  Rechner  aus  dem  Netzwerk  entfernen.  Router  und  Swit¬ 
ches  mit  ausreichend  grofien  Puffern  ausstatten,  um  einen  Paketverlust  vorzubeugen.  Un- 
ter  diesen  Umstanden  kann  man  auch  unter  CSMA/CD  zumindest  statistische  Garantien 
abgeben. 

Auf  der  Wireless  Seite  stellt  die  Storanfalligkeit  von  Aufien  ein  groBes  Problem  dar.  Nichts 
desto  trotz  bietet  das  Pollingverfahren  akzeptable  Voraussetzung  fur  nahezu  Hardrealtime 
Applikationen:  Die  Reaktionszeit  ist  zwar  hoch  und  steigt  mit  der  Anzahl  der  Teilnehmer, 
dafiir  existiert  aber  eine  Schranke  fur  die  maximale  Dauer  bis  zum  nachsten  Mediumzugriff 
einer  Station.  Allerdings  geht  das  nur  unter  der  Nebenbedingung,  dass  der  Master  alle 
Slaves  in  einer  storungsfreien  Umgebung  erreichen  kann. 

(Slotted)  Aloha  ist  auf  Grund  der  hohen  Ineffektivitat  weder  fur  Soft-  noch  fur  Hardre- 
altimesysteme  geeignet.  Dies  wird  auch  nicht  durch  den  Vorteil  der  nicht  vorhandenen 
Verwaltung  von  Aloha  wieder  kompensiert. 


Wenn  bei  DAMA  Slotted  Aloha  zur  Reservierung  verwendet  wird,  kann  es  passieren,  dass 
zwei  oder  mehrere  Stationen  keinen  Timeslot  reservieren  konnen:  Es  kann  keine  obere 
Schranke  tmax  definiert  werden.  Fur  Softrealtime  Applikationen  kommt  hinzu,  dass  das 
Reservierungsverfahren  unnotig  Zeit  kostet. 


MACA  bietet  fur  viele  Teilnehmer  und  weiche  Echtzeitbedingungen  eine  Alternative  zum 
Polling.  Allerdings  wird  dadurch  Overhead  in  Kauf  genommen.  Fur  Hardrealtime  ist  es 
ungeeignet,  da  durch  den  zufalligen  Backolf  Mechanismus  keine  obere  Schranke  definiert 
werden  kann. 
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3.3  Realtimeprotokolle 


Das  nachste  Kapitel  beschaftigt  sich  mit  den  Realtimeprotokollen.  Dabei  werden  die  Pro- 
tokolle  im  OSI/ISO  Referenzstack  eingeordnet  und  spater  insbesondere  auf  ihre  Eignung 
in  WLANs  gepriift. 


Abbildung  3.11:  RTP  und  RTCP  eingeordnet  im  TCP/IP  Stack  [11] 


3.3.1  Realtime  Protocol  (RTP  nach  IETF  RFC3550) 

Das  Realtime  Protocol  setzt  direkt  auf  das  User  Datagram  Protocol  (UDP)  auf.  Nach  dem 
ISO/OSI  Referenzmodell  ist  es  in  der  Ebene  7  /  Applicationlayer  einzuordnen,  obwohl  es 
auch  Meinungen  gibt,  die  RTP  noch  in  die  Ebene  4  /  Transportlayer  einordnen. 

Es  ist  kein  vollstandig  spezifiziertes  Protokoll,  sondern  stellt  wichtige  Funktionen  und 
einen  Rahmen  fur  Softrealtime  Umgebungen  zur  Verfugung.  Da  es  auf  UDP  aufsetzt,  gibt 
es  keine  direkte  Riickmeldung  iiber  Paketverluste.  Es  existiert  auch  kein  Mechanismus 
zur  erneuten  Anforderung  von  IP-Paketen.  Da  RTP  in  erster  Linie  fur  Audio-  und  Video- 
iibertragungen  konzipiert  wurde,  werden  die  Verluste  in  Kauf  genommen,  da  sie  lediglich 
Qualitatseinbufien  produzieren. 

Der  RTP-Header  enthalt  ein  Feld  fur  die  Versionsnummer,  da  mittlerweile  die  Version  2.0 
(RFC  3550)  die  erste  Version  (RFC  1889)  abgelost  hat.  Da  es  fur  manche  Anwendungen 
ein  Vorteil  ist,  Pakete  fester  GroBe  zu  verarbeiten,  gibt  es  ein  Paddingfeld,  indem  die  An- 
zahl  der  aufgefiillten  Paddingbits  steht.  Des  weiteren  enthalt  jeder  Header  eine  Sequenz- 
nummer,  mit  deren  Hilfe  die  Reihenfolge  und  die  Eindeutigkeit  von  Paketen  festgestellt 
werden  kann.  Dariiber  hinaus  werden  die  Pakete  mit  einem  Zeitstempel  versehen,  damit 
Applikation  in  der  Lage  sind,  die  Inhalte  zu  synchronisieren.  Mit  dem  Synchronisation 
Source  Identifier  verfiigt  der  RTP  Header  iiber  ein  Feld,  in  dem  die  Datenquelle  identifi- 
ziert  werden  kann.  Da  RTP  moglichst  flexibel  gehalten  wurde,  existiert  keine  eindeutige 
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Beschreibung  fiir  den  Payload,  sondern  es  existieren  verschiedene  Profile  fur  einzelne  An- 
wendungsgebiete.  Als  Beispiel  sei  hier  die  RFC  2038  fiir  MPEG1  /  2  Video  genannt.  Damit 
eignet  sich  RTP  ausschliefilich,  aber  dafiir  sehr  gut  fiir  Softrealtime  Anwendungen  [8]. 
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Abbildung  3.12:  Der  RTP  Frame  [12] 


3.3.2  Realtime  Transport  Control  Protocol  (RTCP  nach  IETF 
RFC3550) 

Das  RTCP  ist  kein  eigenstandiges  Protokoll,  sondern  eine  Erweiterung  zu  RTP.  Es  setzt 
ebenfalls  auf  dem  UDP  Protokoll  auf.  Fur  die  Dateniibertragung  wird  weiterhin  RTP 
verwendet.  Zusatzlich  aber  werden  kurze  Mitteilungsnachrichten  verschickt,  um  Quali- 
tatsaussagen  liber  die  einzelnen  Verbindungen  zu  treffen. 

Dabei  senden  alle  Sitzungsteilnehmer  regelmaBig  Nachrichten,  so  dass  die  Sendestation 
eine  Ubersicht  hat,  welche  Verbindungsqualitat  jeder  einzelne  Teilnehmer  hat.  Daraufhin 
kann  die  Sendestation  die  Kompressionsraten  der  Daten  anpassen.  Dadurch  werden  die 
einzelnen  Teilnehmer  mit  der  optimalen  Datenmenge  versorgt.  Dariiber  hinaus  konnen 
noch  zusatzliche  Informationen  fiber  die  Teilnehmer  verschickt  werden,  wie  zum  Beispiel 
Name,  eMail  Adresse  usw.  Auch  mit  dem  RTCP  bleibt  RTP  nur  fiir  Softrealtime  Umge- 
bungen  attraktiv  [8]. 


3.3.3  RTnet  der  Universitat  Hannover 

RTnet  wurde  als  Feldbus  Ersatz  mit  Ethernet  Komponenten  konzipiert.  Dabei  wird  der 
herkommliche  ISO/OSI  Referenzstack  schon  ab  der  MAC  Schicht  verandert.  Um  die  Pro- 
bleme  von  CSMA/CD  zu  umgehen,  stellt  die  neue  RTMAC  Schicht  zwei  Verfahren  zur 
Verfiigung:  Ein  Tokenpassing- Verfahren,  bei  dem  mittels  des  Token  die  sendeberechtigte 
Station  ermittelt  wird.  Das  zweite  Verfahren  ist  ein  fester  Zeitmultiplex.  Beide  Verfahren 
erfordern  einen  Master,  der  entweder  das  Token  an  die  richtige  Station  weitergibt,  oder 
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das  Auf-  und  Verteilen  der  Timeslots  bei  TDM  A  iibernimmt.  Als  zusatzliche  Erweiterung 
wird  das  dynamische  ARP  Protokoll  durch  eine  statische  Variante  ersetzt. 

Uber  der  RTMAC  Schicht  setzt  RTnet  auf  UDP  als  Protokoll.  Dariiber  liegen  dann  di- 
rekt  die  Echtzeitapplikationen,  die  direkt  auf  RTnet  zugreifen  konnen.  Da  RTnet  davon 
ausgeht,  dass  im  Netzwerk  lediglich  RTnet  Rechner  sind,  von  denen  ja  immer  nur  eine 
Station  sendet,  wird  der  Einsatz  von  Hubs  und  nicht  von  Switches  empfohlen. 

Um  in  diesem  Netzwerk  aber  auch  gewohnlichen  TCP/IP  Verkehr  zu  ermoglichen,  bietet 
RTnet  eine  zusatzliche  virtuelle  Interface  Schnittstelle  an.  Der  dort  aufkommende  Traffic 
wird  dann  von  RTnet  getunnelt. 

Auf  Grund  dieser  gravierenden  Eingriffe  in  den  TCP/IP  Stack  wird  fiir  jeden  Netzwerk- 
kartenchip  eine  eigene  Implementierung  des  Netzwerktreibers  notig.  Obwohl  fiir  viele  Ka- 
belnetzwerkkarten  Treiber  erstellt  wurden,  existieren  noch  keine  Implementierungen  fiir 
Wireless-Adapter.  Bisher  ist  RTnet  eine  Linuxlosung.  die  sich  aber  auf  andere  Echtzeit- 
betriebssysteme  portieren  lassen  soli.  Die  Realtime  Eigenschaften  fiir  Hardrealtime  hat 
RTnet  bereits  in  Versuchen  unter  Beweis  gestellt.  Dabei  liefie  sich  RTnet  sicher  auch  fiir 
Softrealtime  Umgebungen  einsetzen  [9]. 
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Abbildung  3.13:  Der  Aufbau  von  RTnet  [9] 


3.3.4  Protokolle  Wireless  tauglich? 

RTP  bzw.  die  Kombination  RTCP  setzt  auf  dem  User  Datagramm  Protokoll  auf.  Da  UDP 
auf  Schicht  4  aufsetzt,  spielt  das  eigentliche  Medium  keine  Rolle.  Bei  der  Kombination 
von  RTP/RTCP  werden  durch  die  Berichte  der  einzelnen  Teilnehmer  optimale  Datenraten 
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erzielt.  Dadurch  konnen  sogar  kurzfristige  Beeintrachtigungen  der  Ubertragungsqualitat 
von  mobilen  Systemen  ausgeglichen  werden. 

Des  weiteren  besitzt  UDP  keine  kontraproduktiven  Mechanismen,  wie  TCP.  Im  Wireless 
Fall  werden  Paketverluste  durch  Fehler  bei  der  Ubertragung  von  normalen  TCP  als  Stau 
interpretiert.  Daraufhin  setzt  TCP  die  Datenrate  drastisch  herunter,  obwohl  es  unnotig 
ist.  Es  gibt  zwar  Konzepte  fur  mobile  TCP,  aber  dort  hat  sich  kein  Standard  durchgesetzt. 
RTnet  hingegen  ist  auf  Grund  seiner  Eingriffe  bis  in  die  Schicht  2  auf  eigene  Treiber  an- 
gewiesen.  Bisher  wurde  RTnet  nur  fur  herkommliehe  Kabelnetzwerke  konzipiert,  weshalb 
es  in  der  aktuellen  Version  nicht  auf  WLANs  iibertragbar  ist. 


3.3.5  Kommerzielle  Realtime  Protokolle 

Die  Firma  Hilf !  hat  ein  Protokoll  namens  Realwire  entwickelt.  Die  verfiigbaren  Informatio- 
nen  besagen,  dass  es  auf  UDP  aufsetzt  und  iiber  einen  festgelegten  Zeitmultiplex  verfiigt. 
Genauere  Informationen  liegen  leider  nicht  vor. 

Von  FSMLabs  gibt  es  eine  Variante  von  RTnet  mit  dem  Namen  LNet,  dass  ebenfalls  fur 
RTLinux  konzipiert  wurde.  LNet  soli  den  Applikationen  direkt  zur  Verfiigung  stehen  ohne 
Umwege  iiber  das  Betriebssystem  gehen  zu  miissen.  Dabei  fangt  es  wie  RTnet  die  Pakete 
direkt  nach  nach  der  Schicht  2  ab.  Wie  dies  realisiert  wird,  ist  leider  nicht  beschrieben. 

Die  kommerziellen  Losung  bieten  zwar  den  Vorteil  der  Produktbetreuung,  und  evtl.  der 
Anpassung  an  personliche  Bediirfnisse.  Dafiir  legen  sie  ihre  tatsachliche  Funktionsweise 
nicht  offen,  sondern  beschreiben  lediglich  die  Eigenschaften. 


3.4  Existierende  Systeme 

3.4.1  Roboter  im  Kaufhaus  (RoBoKa) 

RoBoKa  ist  ein  Projekt  des  Lehrstuhls  fur  Rechnerarchitektur  der  Universitat  Rostock. 
Dabei  wurde  ein  Roboter  gebaut,  der  mittels  WLAN  nach  IEEE  802.11  gesteuert  werden 
sollte.  Der  Roboter  konnte  nachts  im  Kaufhof  von  Internetusern  iiber  ein  Java  Applet 
gesteuert  werden.  Dabei  sendete  der  Roboter  bis  zu  30  Bilder  pro  Sekunde.  Gleichzeitig 
erhielt  er  Befehle,  wie  zum  Beispiel  vorwarts,  links  drehen,  rechts  drehen. 

Was  auf  den  ersten  Blick  wie  ein  hartes  Echtzeitsystem  aussieht  (Kollisionsgefahr  des 
Roboters  mit  anderen  Objekten),  wurde  von  den  Verantwortlichen  entscharft,  indem  der 
Roboter  rundum  mit  Ultraschallsensoren  ausgestattet  wurde.  Dadurch  hielt  der  Roboter 
selbststandig  vor  Hindernissen,  anstatt  auf  den  Stoppbefehl  zu  warten  [10]. 
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Abbildung  3.14:  Foto  vom  Roboter  im  Kaufhaus  [10] 


3.5  Zusammenfassung 

3.5.1  Fazit 

Im  Gegensatz  zu  Token  Ring,  das  Hardware  und  Topologie  abhangig  ist,  lasst  sich  der 
logische  Ring  von  Token  Bus  auch  auf  andere  Systeme  iibertragen.  Dariiber  hinaus  bietet 
Token  Ring  keine  Moglichkeit,  den  maximalen  Zeitpunkt  der  erneuten  Mediumzuteilung 
zu  bestimmen.  Damit  bietet  Token  Ring  fur  harte  Realtimenetzwerke  keine  Losung.  Da 
TokenBus  einen  maximalen  Zeitpunkt  bis  zur  erneuten  Zuteilung  der  Sendeberechtigung 
besitzt,  lasst  es  sich  problemlos  auch  fur  Hardrealtime  Anwendungen  einsetzten.  Dafiir 
wurde  es  urspriinglich  auch  von  GM  konzipiert. 

Netzwerke  mit  CSMA/CD  lassen  sich  selbst  mit  Aufwand  in  der  Konzeption  und  im 
Aufbau  nur  bedingt  fur  Realtime  Umgebungen  einsetzen.  Wahrend  man  bei  kleinen  Da- 
tenmengen  und  einer  geringen  Teilnehmerzahl  noch  sehr  gute  Ergebnisse  erzielt,  steigt 
mit  grofieren  Datenaufkommen  und  hoherer  Teilnehmerzahl  deutlich  das  Risko,  dass  Zeit- 
punkte  nicht  mehr  eingehalten  werden  konnen.  Allerdings  bieten  sie  fur  heutige  Softreal- 
time  Applikationen  mehr  als  geniigend  Bandbreite  und  schnelle  Reaktionszeiten  fur  die 
Bedufnisse  einer  begrenzten  Benutzerzahl. 

Die  Zugriffsverfahren  bei  WLAN  besitzen  alle  Einschrankungen:  Entweder  sie  versuchen 
die  wireless  typischen  Probleme  zu  behandeln,  oder  sie  machen  Vorgaben,  unter  welchen 
Bedingungen  das  Verfahren  funktioniert.  Zu  alledem  kommt  noch  die  Storanfalligkeit 
von  WLANs,  so  dass  sie  unter  keinen  Umstanden  fiir  kritische  Echtzeitsysteme  geeignet 
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sind.  Mit  Polling  gibt  es  zwar  ein  Verfahren,  dass  Zeitgarantien  abgeben  kann,  allerdings 
stets  unter  der  Voraussetzung,  dass  es  keine  ausseren  Storquellen  gibt.  Fur  Softrealtime 
Umgebungen  sind  bis  auf  (Slotted)  Aloha  alle  Verfahren  geeignet,  da  mittlerweile  fur 
WLANs  ausreichend  Bandbreite  zur  Verfiigung  stehen. 

Bei  den  Protokollen  erkennt  man  in  den  zwei  vorgestellten  Verfahren,  je  einen  Vertreter  fur 
Soft-  bzw.  Hardrealtime.  Wahrend  RTP/RTCP  fur  Audio/Videodaten  optimiert  wurde, 
haben  die  Entwickler  von  RTnet  insbesondere  auf  deterministische  Zeitaussagen  Wert  ge- 
legt.  Dieser  Unterschied  zeigt  sich  auch  deutlieh  an  den  Modifizierungen  des  OSI/ISO  Refe- 
renzstacks:  RTP/RTCP  setzt  auf  UDP  auf,  ohne  an  den  restlichen  Schichteh  Anderungen 
vorzunehmen.  Dadurch  spielt  auch  das  Ubertragungsmedium  keine  Rolle.  Durch  die  regel- 
mafiigen  Sende-  und  Empfangsberichte  konnen  sogar  leichte  Schwankungen  von  Wireless 
Verbindungen  durch  Anpassung  der  Datenraten  ausgeglichen  werden.  RTP/RTCP  sind 
freie  Standards  fur  das  Internet. 

Bei  RTnet  wird  der  ISO/OSI  Referenzstack  bereits  ab  der  Schicht  2  modifiziert,  was  spezi- 
elle  Treiber  erfordert.  Dafiir  kann  RTnet  Zeitgarantien  abgeben  und  ist  dariiber  hinaus  als 
kostenlose  Implementierung  erhaltlich.  Zudem  wird  RTnet  standig  weiterentwickelt,  was 
die  bereits  jetzt  erzielten  Eigenschaften  verbessert,  bzw.  RTnet  um  weitere  Eigenschaften 
erweitert. 


3.5.2  Ausblick 


In  Zukunft  werden  vor  allem  Softrealtime  Applikationen  immer  mehr  Einzug  in  Computer- 
systeme  halten.  Insbesondere  Audio-  und  Videoiibertragungen,  aber  auch  Computerspiele 
werden  die  Netzwerke  der  Zukunft  belasten.  Dabei  hat  sich  aber  schon  gezeigt,  dass  die 
aktuellen  Systeme,  egal  ob  mit  Kabel  oder  ohne,  ausreichend  fur  die  Beiirfnisse  der  meis- 
ten  heutigen  Nutzer  sind.  Daher  werden  zukunftig  die  Datenraten  in  Verbindung  mit  den 
steigenden  Anforderungen  der  User  weiter  steigen.  Getreu  dem  Motto:  „Warum  soli  ich 
mich  mit  500KBits  zufrieden  geben,  wenn  ich  2MBits  haben  kann?“ 

Im  Bereich  der  Mediumzugriffsverfahren  werden  keine  Revolutionen  mehr  erwartet,  son- 
dern  nur  noch  Optimierungen  der  vorhandenen  Methoden.  Durch  bessere  Hardware  Kom- 
ponenten  konnen  Sicherheitsabstande  zwischen  einzelnen  Ubertragungen  weiter  reduziert 
werden.  Zusatzlich  ermoglichen  bessere  Komponenten  kiirzere  Synchronisierungsabschnit- 
te  bei  WLANs.  Dabei  werden  die  Reaktionszeiten  von  Funknetzwerken  hinter  den  Werten 
der  Kabellosungen  liegen  bleiben.  Dies  liegt  an  den  charakteristischen  Merkmalen  des  ka- 
bellosen  Mediums.  Die  Auswirkungen  lassen  sich  zwar  minimieren,  aber  auch  in  Zukunft 
nicht  beseitigen. 

Auf  Grund  der  grofien  Verbreitung  und  den  kostengiinstigen  Hardwarekomponenten  gibt 
es  immer  mehr  Projekte,  die  versuchen,  Protokolle  wie  RTnet  zu  entwickeln,  damit  Ether¬ 
net  als  Ersatz  zu  teuren  Bussystemen  verwendet  werden  kann.  Sie  basieren  aber  in  der 
Regel  darauf,  dass  man  einen  stark  verkiirzten  OSI/ISO  Referenzstack  verwendet,  und 
auf  verbindungslose  Protokolle,  wie  zum  Beispiel  UDP  setzt. 
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Die  Technik  der  Zukunft  wird  die  Echtzeiteigenschaften  der  Netzwerktechniken  immer 
weiter  verbessern:  Kurzere  Reaktionszeiten,  mehr  Bandbreite,  Garantien  fur  Mediumzu- 
griffe,  usw.  Aber  das  ideale  Netzwerk  wird  man  nicht  erreichen  konnen. 
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Kapitel  4 


Micro-Mobility  in  IP-based 
Networks 

Philipp  Appelhoff 


In  der  unmittelbaren  Vergangenheit  hat  die  IETF  Mobile  IP  Working  Group  eine  Rei- 
he  von  Erweiterungen  des  bekannten  Mobile  IP  Protokolls  behandelt,  das  Mitte  der  90er 
Jahre  entwickelt  wurde,  um  der  in  naher  Zukunft  radikal  wachsenden  Zahl  von  sogenann- 
ten  Wireless  Subscribem,  also  Nutzern  mobiler  Datenkommunikationsdienste,  gerecht  zu 
werden  und  ihnen  die  gleichen  Moglichkeiten  zu  bieten,  die  sie  aus  drahtgebundenen  Netz- 
werken  kennen.  Bekanntlich  ergeben  sich  mit  uiachsender  Mobilitat  und  der  immer  schnel- 
leren  Verbreitung  kabelloser  Kommunikationssysteme  diverse  Herausforderungen,  denen 
IP-basierte  Systeme  aufgrund  des  Konzepts  der  hierarchischen  Adressierung  nicht  ohne 
weiteres  gerecht  werden  konnen.  Mit  dem  Mobile  IP  Protokoll  wurde  eine  Losung  vorge- 
stellt,  die  es  dem  Nutzer  ermoglicht,  an  einem  beliebigen  Ort  mit  Zugang  zum  Internet 
auch  unter  seiner  alten  Adresse  erreichbar  zu  sein.  Steigt  jedoch  die  Geschwindigkeit  der 
Fortbewegung  und  damit  die  Frequenz  der  zu  erwartenden  Zellenwechsel,  wird  die  mangeln- 
de  Effizienz  des  Protokolls  deutlich.  Micro- Mobility  Protokolle  erweitern  daher  den  Ansatz 
von  Mobile  IP,  um  das  Basisprotokoll  mit  Hilfe  von  Handoff-Optimierung  und  Paging,  mit 
der  Strukturierung  von  Netzen  und  effizienteren  Sicherheitskonzepten  zu  verbessern.  Diese 
Arbeit  stellt  dabei  kurz  die  Probleme  von  Mobile  IP  heraus,  gibt  anschliessend  einen  Uber- 
blick  iiber  verschiedene  Ansatze,  um  anschliefiend  einige  bekannte  und  charakteristische 
Protokolle  und  Konzepte  (Fast  und  Proactive  Handoff,  Hierarchical  Mobile  IP,  Cellular 
IP  und  Hawaii)  vorzustellen.  Mit  Hilfe  der  Columbia  Micro-Mobility  Suite  (CMS)  [17] 
werden  die  drei  zuletzt  genannten  Protokolle  auf  Basis  bestehender  Implementierungen 
verglichen,  um  die  gewahlten  Ansatze  schliefilich  zu  bewerten. 
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Es  ist  nicht  mehr  zu  iibersehen,  dafi  drahtlose  Kommunikationsgerate  mittlerweile  auch 
den  Bereich  der  IP-basierten  Netze  erreicht  haben.  Bereits  im  Jahre  2000  waren  20%  aller 
verkauften  PC's  tragbar  [19].  Durch  die  Medien  kennt  bereits  heute  jeder  Begriffe  wie 
WLAN,  Bluetooth  oder  auch  UMTS.  Mobilitat  ist  zum  Standard  geworden,  hinter  dem 
jedoch  viel  mehr  steckt  als  nur  auf  Kabel  zu  verzichten,  oder  wie  es  die  Werbung  eines 
grofien  deutschen  Kommunikationsanbieter  ausdriickt,  kabellos  online  zu  sein.  Dennoch 
erwartet  der  Konsument  von  den  neuen  Technologien  gleiche  Leistungen,  wie  er  sie  mitt¬ 
lerweile  von  seinem  Desktop-PC  kennt.  Mit  dem  Internet  fest  verkabelt  ladt  er  Musik  aus 
dem  Netz  oder  hort  einen  New  Yorker  Radiosender  per  Internet.  Zudem  wird  die  Zukunft, 
vielleicht  mit  der  Etablierung  von  ,yoice  over  IP“  als  konkurrenzfahiges  Telekommunika- 
tionsmedium,  ganz  neue  Erwartungen  an  bestehende  Netzwerke  stellen. 

Innerhalb  von  IP-basierten  Netzen  werden  IP-Adressen  jedoch  dazu  genutzt,  um  sowohl 
den  MN  als  auch  dessen  Position  im  Netz  eindeutig  zu  bestimmen.  Offensichtlich  ergeben 
sich  ganz  neue  Probleme  und  Herausforderungen,  wenn  Gerate  in  solchen  IP-basierten 
Netzen  mobil  werden,  denn  dann  ist  es  nicht  mehr  moglich,  die  Position  des  Empfangers 
ohne  weiteres  liber  dessen  IP-Adresse  zu  bestimmen.  Gleichzeitig  sehen  IP-basierte  Netze 
den  Wechsel  der  Adresse  nicht  vor,  da  Mobilitat  bei  der  Entwicklung  des  Standards  nicht 
beriicksichtigt  wurde.  Das  erste  Protokoll,  das  sich  mit  diesen  Problemen  befasste,  war 
Mobile  IP.  Dieses  Protokoll  wird  als  erstes  in  dieser  Seminararbeit  vorgestellt,  um  eine  kur- 
ze  Einfiihrung  in  die  Funktionsweise  mobilitatsorientierter  Protokolle  zu  geben.  Danach 
sollen  die  Grenzen  des  Protokolls  aufgezeigt  werden,  die  insbesondere  in  der  aufwendigen 
Behandlung  von  Zellenwechseln  begriindet  sind.  Um  den  Problemen  zu  begegnen,  wurde 
der  Begriff  von  Mikromobilitat  eingefuhrt,  der  Mobilitat  in  enger  begrenzten  Bereichen 
behandeln  soli  und  auf  quasi  nahtlose  Ubergange  zwischen  verschiedenen  Netzwerkzu- 
gangspunkten  ausgerichtet  ist.  Dazu  wurden  verschiedene  Optimierungsansatze  herausge- 
arbeitet,  um  Probleme  des  Mobile  IP  Protokolls  zu  beseitigen  oder  deren  Auswirkungen 
zu  minimieren.  Nachdem  diese  Ansatze  erlautert  wurden,  werden  im  Kapitel  4.4  verschie¬ 
dene  charakteristische  Protokolle  beschrieben.  Diese  stellen  nur  einen  kleinen  Ausschnitt 
aus  bestehenden  Ansatzen  dar.  Wahrend  die  Protokolle  Fast  und  Proactive  Handoff  eher 
als  Konzeptstudien  zu  sehen  sind,  werden  mit  Hierarchical  Mobile  IP,  Cellular  IP  und 
Hawaii  drei  Protokolle  vorgestellt,  die  basierend  auf  bestehenden  Implementierungen  im 
Abschnitt  4.5  verglichen  werden  sollen.  Abschliessend  werden  dann  die  verschiedenen  An¬ 
satze  bewertet  und  verglichen  und  einige  Probleme  angesprochen. 
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4.2  Micro-Mobility  vs.  Macro-Mobility 
4.2.1  Mobile  IP 

Mobile  IP  ist  das  wohl  bekannteste  Konzept,  das  sich  mit  den  Herausforderungen  von  Mo- 
bilitat  in  IP-basierten  Netzwerken  befasst.  Mobile  Kommunikationsgerate,  im  Folgenden 
als  MN  -  Mobile  Nodes  bezeichnet,  werfen  Probleme  auf,  die  mit  bestehenden  Systemen 
nicht  zu  bewaltigen  sind.  Wenn  sich  ein  MN  in  solchen  IP-basierten  Netzen  bewegen  soil, 
muss  sich  folgerichtig  auch  seine  IP-Adresse  andern  und  ankommende  Pakete  umgeleitet 
werden.  Bei  der  Entwicklung  IP-basierter  System  wurden  solche  Aspekte  jedoch  nicht  be- 
riicksichtigt,  sodafi  Erweiterungen  diesen  Rechnung  tragen  miissen.  Dieser  Aufgabe  wid- 
mete  sich  die  Mobile  IP  Working  Group  erstmalig  mit  der  Entwicklung  des  Mobile  IP 
Protokolls,  das  folgenden  Kriterien  gentigen  sollte: 


•  Erweiterung  des  statischen  IP-Konzeptes  um  Mobilitat 

•  Erreichbarkeit  von  mobilen  Kommunikationspartnern  ausserhalb  ihrer  Netze 

•  Kompatibilitat  mit  bestehenden  Systemen  und  Transparenz 

•  einfache  Erweiterbarkeit 

•  Sicherheit  und  Effizienz 


Dig  Tatsache,  dafi  gerade  die  Effizienz  nicht  umgesetzt  wurde,  bildet  die  Grundlage  dieser 
Arbeit.  Aber  zuvor  soil  die  grundsatzliche  Funktionsweise  hier  vorgestellt  werden.  Mo¬ 
bile  IP  erlaubt  es  einem  MN,  seinen  WIPPOA  (Wireless  IP  Point  of  Attachment,  nach 
[4])  beliebig  zu  wechseln.  Dieser  andert  damit  zum  einen  den  Anschluss  an  das  Netzwerk 
selbst,  indem  er  sich  zum  Beispiel  einem  neuen  WLAN-Accesspoint  anschliefit,  zum  an- 
deren  muss  er  die  eindeutige  Kennung  innerhalb  dieses  Netzes,  seine  IP-Adresse,  andern. 
Fiir  das  Angebot  einer  solchen  neuen  Adresse  ist  ein  sogenannter  Foreign  Agent  (FA) 
zustandig,  der  im  jeweiligen  Netz  regelmaSige  Agent  Advertisements  verschickt  und  dem 
MN  damit  einen  Zellenwechsel  signalisiert.  Das  Heimatnetz  besitzt  als  Komplement  zum 
FA  einen  sogenannten  Home  Agent  (HA).  Er  ist  bei  Abwesenheit  des  MN  dafiir  verant- 
wortlich,  alle  an  den  MN  gerichteten  Pakete  abzufangen  und  an  dessen  Aufenthaltsort 
umzuleiten.  Dafiir  bekommt  der  MN  neben  seiner  statischen  IP  aus  dem  Heimnetz  vom 
FA  ahnlich  zu  DHCP  eine  neue,  im  fremden  Netz  giiltige  Adresse,  die  Care-Of-Address 
(COA).  Sobald  ein  FA  dem  neuen  MN  eine  COA  zugeteilt  hat,  muss  der  HA  dariiber 
informiert  werden.  Innerhalb  dieses  Registrierungsprozesses  andert  der  HA  den  Eintrag  in 
seiner  Liste  und  sendet  daraufhin  alle  Pakete,  die  den  MN  aus  dem  Heimatnetz  erreichen 
sollen,  an  die  entfernte  COA  (siehe  Abbildung  4.1).  In  der  Abbildung  sind  einige  Rou¬ 
ter  angedeutet,  die  alle  vom  einem  fremden  Kommunikationsgerat  (CN  -  Correspondent 
Node)  an  den  MN  adressierten  Pakete  in  das  Heimatnetz  leiten.  Der  HA  sendet  sie  per 
Adressersetzung  oder  Tunneling  in  das  fremde  Netz  weiter.  Im  neuen  Netz  iibernimmt 
der  FA  die  Zustellung  an  den  MN.  In  diesem  Bild  ist  das  sogenannte  Reverse  Tunneling 
angedeutet,  wo  der  HA  auch  als  Bindeglied  in  der  entgegengesetzten  Richtung  fungi ert. 
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Abbildung  4.1:  Mobile  IP  mit  Reverse  Tunneling 


Weitere  Moglichkeiten  sollen  hier  verschwiegen  werden,  sind  jedoch  in  [14]  detailliert  be- 
schrieben.  Offensichtlich  wird  der  CN  durch  die  Einfiihrung  des  Mobile  IP  Protokolls  nicht 
beeinflusst,  fur  ihn  bleibt  das  Protokoll  transparent. 


4.2.2  Probleme  von  Mobile  IP 

Das  Konzept  von  Mobile  IP  ist  immer  dann  vollkommen  ausreichend,  wenn  die  Frequenz 
von  Zellenwechseln  sehr  niedrig  ist.  In  diesem  Zusammenhang  kann  man  eher  von  einer 
drahtlosen  Kommunikation  sprechen,  weil  das  Protokoll  in  quasi  statischen  Anwendungs- 
fallen  gut  funktioniert.  Im  Fokus  der  Uberlegungen  zu  Mikro-Mobilitat  stehen  jedoch 
Situationen,  in  denen  der  MN  haufige  Zellenwechsel  erfahrt.  Automatisch  ist  damit  in 
Mobile  IP  jedoch  ein  aufwendiger,  sich  bei  jedem  Zellenwechsel  wiederholender  Regis- 
tierungsprozess  verbunden.  Wahrend  eines  solchen  Zellenwechsels,  im  weiteren  auch  als 
Handoff  bezeichnet,  miissen  Paketverluste  und  Verzogerungen  in  Kauf  genommen  werden. 
Gleichzeitig  benotigen  Anwendungen  aber  unter  Umstanden  Zeitgarantien,  z.B.  bei  Voice 
over  IP  (VoIP).  Bei  jedem  Zellenwechsel  treten  zwei  Arten  der  Verzogerung  auf: 

•  Unter  Move  Detection  Latency  versteht  man  die  Verzogerung  tMD,  die  durch  das 
Erkennen  eines  Zellenwechsels  auf  der  IP-Schicht  entsteht.  Da  die  Schichten  im 
ISO/OSI-Referenzmodell  strikt  voneinander  getrennt  sind,  ist  es  nicht  beabsich- 
tigt,  dafi  die  Schicht  3  von  einem  Wechsel  des  Point  of  Attachment  informiert  wird. 
Um  also  einen  Zellenwechsel  zu  registrieren,  sind  in  Mobile  IP  zwei  Moglichkeiten 
vorgesehen:  In  regelmafiigen  Zeitabstanden  t^dv  sendet  ein  FA  sein  Agent  Adverti¬ 
sement.  Weiterhin  kann  der  MN  auf  das  Ende  der  COA-Lebenszeit  tcoA  warten, 
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Abbildung  4.2:  Die  Trennung  von  Makro-  und  Mikromobilitat 

und  dann  ein  neues  Advertisement  Request  senden.  Die  Handoff-Erkennung  auf  der 
IP-Schicht  verzogert  sich  um  t^o  min(L4rfu>  too  a)-  Dabei  stehen  die  Minimie- 

rung  des  Signal-Overheads  innerhalb  des  Netzes  im  Widerspruch  zur  Minimierung 
der  Move  Detection  Latency  durch  haufige  Advertisements  (t^dv  — 4  0)  oder  geringe 
Lebenszeiten  der  COA  (too a  —*  0).  Ansatze  zur  Losung  dieses  Problems  finden  sich 
in  4.3.1. 

•  Die  zweite  Verzogerung,  die  Registration  Latency  [4]  entsteht  durch  den  Registrie- 
rungsprozess  der  COA  beim  HA.  Dieser  muB  nach  dem  Konzept  von  Mobile  IP  bei 
jedem  Zellenwechsel  iiber  die  neue  COA  des  MNs  informiert  werden.  Da  der  HA  im 
Allgemeinen  nur  iiber  das  Internet  erreichbar  ist,  wird  tneg  sehr  groB. 


In  dieser  Zeit  (t^D  +  I  Reg)  werden  alle  vom  HA  weiterzuleitenden  Pakete  an  die  alte, 
nunmehr  falsche  COA  gesendet.  Um  wieder  das  Beispiel  von  VoIP  zu  nehmen,  waren  die 
Pakete  auf  dieser  UDP-Verbindung  verloren.  Wiirde  man  TCP  zugrunde  legen,  ware  das 
Problem  sicher  nicht  behoben.  Zum  einen  wiirde  die  zur  Verfiigung  stehende  Bandbreite 
des  Netzes  mehrfach  beansprucht,  zum  anderen  hatte  man  nun  das  Problem  des  Paket- 
verlusts  durch  erhebliche  Verzogerungen  ersetzt.  Um  diesem  Problem  zu  begegnen,  sind 
diverse  Ansatze  veroffentlicht  worden,  die  in  den  Punkten  4.3.2  bis  4.3.4  naher  erlautert 
werden. 


4.2.3  Definition  von  Micro-Mobility 

Die  im  Konzept  eines  Mobile  IP  Handovers  begriindeten  Verzogerungen  waren  der  In¬ 
itiator  fur  die  Abgrenzung  der  Begriffe  der  Mikro-  und  Makro-Mobilitat  und  die  daraus 
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resultierenden  neuen  Ansatze.  Der  sogenannte  „Micro  Mobility  Approach11  [4]  trennt  die 
Begriffe  wie  folgt:  Nach  dem  Schema  regelt  das  Mobile  IP  Protokoll  den  Wechsel  zwi- 
schen  voneinander  weit  entfernten  oder  durch  das  Internet  getrennten  Netzen  nach  oben 
vorgestelltem  Prinzip,  man  spricht  in  dieser  Dimension  von  Makro-Mobilitat.  Die  zugrun- 
deliegende  Netztopologie  im  makromobilen  Bereich,  bei  der  davon  auszugehen  ist,  das 
regelmafiige  Domanenwechsel  eher  die  Ausnahme  sind,  macht  Optimierungsversuche,  auf 
denen  im  folgenden  Wert  gelegt  wird,  weitgehend  unnotig,  da  das  Verhaltnis  zwischen 
Aufwand  und  Nutzen  gering  ware.  Dementsprechend  wird  der  Makro-Bereich  in  dieser 
Arbeit  nicht  mehr  naher  betrachtet.  Im  Gegensatz  dazu  werden  einzelne  Subnetze  mit 
gemeinsamen  Eigenschaften  zusammengefasst  (siehe  Abbildung  4.2).  Wahtend  sich  der 
MN  innerhalb  dieser  Netze  bewegt,  iibernimmt  ein  Micro  Mobility  Protokoll  die  Lokali- 
sierung  des  MNs.  Mithilfe  dieser  Trennung  kdnnen  speziellere  Losungen  gefunden  werden, 
die  bei  Mobile  IP  aufgrund  des  Allgemeingultigkeit  und  Dimension  nur  ansatzweise  rea- 
lisierbar  waren.  Dieses  Micro-Mobility  Protokoll  muss  fur  Mobile  IP  im  makro-mobilen 
Bereich  transparent  bleiben.  Auf  Grunglage  dieser  Annahme  haben  sich  viele  Protokol- 
le  entwickelt,  die  Probleme  von  Mobile  IP  mit  Ansatzen  wie  Fast  Handoff,  Paging  oder 
Hierarchical  Mobility  angehen. 


4.3  Optimierungsansatze  von  Micro-Mobility 

4.3.1  Schnelle  Handoff-Erkennung 


Unter  Handoff-Optimierung  versteht  mail  Ansatze,  die  Zeit  bis  zum  vollstandigen  Ab- 
schluss  eines  Zellenwechsels  t Handover  zu  minimieren.  Die  IETF  Mobile  IP  Working  Group 
hat  dazu  einige  Ansatze  zusammengestellt: 

Ziel  all  dieser  Ansatze  ist  es,  von  der  Schicht  2  einen  Hinweis  zu  bekommen,  damit  das 
meist  auf  schicht  3  angesiedelte  Micro-Mobility  Protokoll  schneller  reagieren  kann.  Bei 
der  sogenannten  Layer  3  Movement  Detection  versucht  man  Informationen  iiber  den  neu¬ 
en  FA  zu  erhalten,  bevor  ein  Handoff  auf  Ebene  2  stattfindet.  Dabei  wird  stets  von  der 
Lockerung  der  Grenzen  zwischen  den  Schichten  2  und  3  gesprochen,  um  Handover  auf  Ebe¬ 
ne  3  durch  ein  Handoff  auf  der  darunterliegenden  Ebene  zu  initiieren.  Dieser  Ansatz  ist 
nicht  trivial,  zumal  er  die  strikte  Schichtentrennung  des  ISO/OSI-Referenzmodells  iiber- 
geht,  und  damit  zusatzlich  die  generelle  Applikabilitat  reduziert.  Andererseits  konnen  von 
Schicht  2  getriggerte  Handover  grofie  Effizienzsteigerungen  erzielen,  z.B.  in  Signalstarke- 
basierten  Handover-Schemata.  Aufgrund  der  zahlreichen  verschiedenen  mobilen  Gerate 
und  Standards  ist  es  jedoch  kaum  mdglich,  die  Trennung  zwischen  den  Schichten  im  allge- 
meinen  Fall  aufzubrechen,  ohne  dabei  auf  linkspezifische  Eigenheiten  eingehen  zu  miissen. 
Andrew  T.  Campbell  [2]  spricht  in  diesem  Zusammenhang  von  dem  Bedarf  einer  „Open 
Radio  API",  um  die  Gemeinsamkeiten  der  verschiedenen  Systeme  herauszustellen  und 
von  linkspezifischen  Details  abstrahieren  zu  kdnnen.  Ein  elementarer  Teil  weiterer  Lo- 
sungsansatze  im  Bereich  des  Handoffs  sind  Buffer-  und  Forwardingtechniken  wahrend  des 
Handovers,  wobei  Pakete  auf  mehreren  Wegen  geroutet,  teilweise  „verlangsamt“  und  so- 
mit  an  verschiedenen  FAs  empfangen  werden  kdnnen.  Dadurch  wiirde  sich  die  Dauer  des 
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Paketverlustes  theoretisch  (vgl.  4.4.3)  auf  die  Lange  des  L2-Handoffs  beschranken,  also 
den  Wechsel  des  Accesspoints. 


4.3.2  Hierarchical  Mobility 

Hierarchical  Mobility  Management  etabliert  den  bereits  angesprochenen  Ansatz  in  Micro- 
Mobility-Protokollen,  lokale  Bewegungen  von  MNs  ausschlieBlich  lokal  zu  behandeln.  Da- 
zu  wird  das  Netz  hierarchisch  zusammengefasst  und  mit  diversen  Knotenpunkten  un- 
terschiedlicher  Funktion  versehen.  Eine  solche  Struktur  ist  in  Abbildung  4.3  dargestellt. 
Wahrend  sich  der  MN  in  diesem  eng  begrenzten  Netz  frei  bewegt,  kann  er  seinen  WIP- 
POA  wechseln,  ohne  daB  ein  Knoten  ausserhalb  dieses  Netzes  informiert  werden  miisste, 
was  zur  Folge  hat,  dafi  der  Wechsel  fur  den  HA  transparent  bleibt.  Dadurch  entfallt  die 
zeitaufwendige  Registrierurig  beim  Home  Agent,  die  bei  Bewegungen  im  Subnetz  somit 
iiberfliissig  ist,  da  fast  die  gesamte  Routing-Strecke,  namlich  bis  zum  Gateway,  identisch 
geblieben  ist. 

Innerhalb  des  Netzes  wird  dann  ein  Micro-Mobility  Protokoll  die  Zustellung  der  Pakete 
zum  aktuellen  Accesspoint  iibernehmen.  Dazu  benutzen  die  Protokolle  eine  sogenannte 
Location  Database,  in  der  die  MNs  auf  Informationen  zum  Aufenthaltsort  abgebildet  wer¬ 
den.  Die  meisten  Protokolle  setzen  dafiir  Knoten  vorraus,  die  eine  eigene  Mobile-Routing- 
Tabelle  fiihren,  und  diese  fur  jedes  ankommende  Paket  durchsuchen.  Den  Tabellenein- 
tragen  werden  Timer  zugeordnet,  sodafi  sie  regelmaBig  aktualisiert  werden  miissen,  oder 
nach  einer  vordefinierten  Zeit  trTL  entfernt  werden.  In  Micro-Mobility  Protokollen  unter- 
scheidet  man  zwei  grundlegende  Konzepte,  die  unter  dem  Begriff  hierarchical  Mobility11 
zusammmengefasst  werden: 

# 


Internet 


Abbildung  4.3:  Eine  Domane  mit  Gateway  und  Foreign- Agent  Hierarchie 
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Abbildung  4.4:  Das  Prinzip  von  Hierarchical  Tunneling 

Hierarchical  Tunneling 

Wie  der  name  schon  sagt,  ist  dies  ein  Ansatz,  nach  dem  alle  relevanten  Knoten  in  der 
Hierarchie  mit  einzelnen  Tunneln  verbunden  sind,  an  dessen  Enden  der  Gateway  bzw.  der 
MN  sind.  Die  Datenbank  ist  auf  einige  Knoten  innerhalb  des  Netzes  verteilt.  Zwischen  den 
FAs  werden  die  Pakete  getunnelt,  wahrend  sie  am  jeweiligen  FA  entkapselt  und  mit  einer 
neuen  Ziel-IP,  also  der  des  folgenden  FAs  wieder  per  IP-in-IP-Kapselung  getunnelt  werden. 
Dies  hat  den  Vorteil,  dafi  Protokolle  nach  diesem  Konzept  problemlos  in  bestehende  Netze 
integriert  werden  konnen,  da  das  normale  IP-Routing  die  gekapselten  Pakete  an  den  FA 
weiterleitet  (siehe  Abbildung  4.4).  Zur  Aktualisierung  der  jeweiligen  Eintrage  werden  vom 
MN  spezielle  Registration  Messages  gesendet,  damit  die  Eintrage  an  den  speziellen  Knoten 
aktualisiert  werden.  Ein  Protokoll,  das  auf  diesem  Prinzip  basiert,  ist  Hierarchical  Mobile 
IP  (Kapitel  4.4.1). 


Mobile-Specific  Routing 

Mobile-Specific  Routing  vermeidet  den  Aufwand,  Pakete  an  jedem  FA  entkapseln  und  nach 
Suche  des  Folge-FAs  wieder  kapseln  zu  miissen.  Statt  dessen  wird  Routing  benutzt,  um 
die  Pakete  an  den  jeweiligen  WIPPOA  des  MN  zu  leiten.  Da  diese  Protokolle  auf  Tunneln 
verzichten,  miissen  alle  Router  dieser  Systeme  auch  erweitertes  Mobility-Routing  beherr- 
schen  und  sind  daher  nicht  in  bestehende  Systeme  integierbar.  Um  die  Routingeintrage 
zu  aktualisieren,  werden  zwei  Ansatze  unterschieden: 


•  implizite  Aktualisierungen  durch  die  Pakete  vom  MN 
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•  explizite  Signalisierung  durch  Registration  Messages 


Beispiele  fiir  Protokolle,  die  auf  Mobile-Specific  Routing  basieren,  sind  Cellular  IP  und 
Hawaii,  die  im  Kapitel  4.4  vorgestellt  werden. 


4.3.3  Paging 

Wahrend  man  bei  fest  mit  dem  Internet  verbundenen  Geraten  wie  einem  Desktop-PC 
davon  ausgeht,  dafi  er  stets  erreichbar  ist  und  dabei  fiber  praktisch  beliebige  Energiereser- 
ven  verffigt,  ist  dies  bei  der  Betrachtung  von  mobilen  Geraten  nicht  der  Fall.  Insbesondere 
mobile  Kommunikationsgerate  zeichnen  sich  dadurch  aus,  dafi  sie  nur  endliche,  sogar  recht 
geringe  Reserven  nutzen  konnen  und  die  meiste  Zeit  nicht  aktiv  kommunizieren.  Paging 
betrachtet  daher  die  Minimierung  des  Energieverbrauchs  unter  dem  Aspekt  der  optimalen 
Netzanbindung.  Denn  auch  der  Nutzer  von  Mobilkommunikationsgeraten  erwartet  einen 
ahnlichen  Service  wie  bei  fest  verkabelten  Geraten,  jederzeit  quasi  unmittelbar  auf  beliebi¬ 
ge  Internetressourcen  zugreifen  zu  konnen  [2,  S.  46]  und  u.  U.  stets  erreichbar  zu  sein.  Man 
kann  davon  ausgehen,  dafi  ein  MN  nur  zu  einem  Bruchteil  der  Zeit,  in  der  er  eingeschaltet 
ist,  tatsachlich  kommuniziert.  In  der  Zwischenzeit  wird  bei  Mobile  IP  stets  Energie  ver- 
braucht,  um  mindestens  alle  tTTL  Sekunden  eine  erneute  Registierung  im  aktuellen  Netz 
durchzuffihren,  damit  es  stets  die  aktuelle  Position  kennt. 

Wenn  man  jetzt  voraussetzt,  dafi  es  ausreicht,  wenn  das  Netz  nur  noch  einen  nahezu  be- 
liebig  ungenauen  Standpunkt  kennt,  dann  muss  der  MN  sehr  viel  seltener  kommunizieren. 
Also  wird  dem  MN  erlaubt,  in  einen  Zustand  zu  wechseln,  in  dem  er  nicht  gezwungen 
ist,  regelmafiige  Registration  Messages"  zu  senden,  sondern  sich  passiv  zu  verhalten.  Ein 
moglicher  Ansatz  ist  es,  das  zugrunde  liegende  Netz  in  Paging-Bereiche  einzuteilen.  Wah¬ 
rend  sich  der  passive  MN  innerhalb  dieser  Paging- Area  (PA)  bewegt,  ist  eine  erneute 
Registrierung  nicht  notwendig.  er  mufi  lediglich  fiber  die  aktuelle  PA  informieren  und  auf 
eingehende  Verbindungen  warten.  Wenn  eine  solche  kommt,  wird  durch  wieder  eine  ak- 
tive  Bindung  an  das  Netz  hergestellt.  In  der  Zwischenzeit  genfigt  es,  wenn  der  MN  den 
Wechsel  der  PA  bemerkt.  Paging- Verfahren  sind  insbesondere  in  dem  Protokollen  Cellular 
IP  und  Hawaii  (siehe  Kapitel  4.4)  beschrieben,  aber  auch  fiir  das  Hierarchical  Mobile  IP 
Protokoll,  das  in  4.4.1  beschrieben  ist,  gibt  es  eine  Paging-Erweiterung. 


4.3.4  Fast  Security 

Um  es  vorweg  zu  nehmen:  Man  kann  keine  generelle  Aussage  fiber  den  Bedarf  an  Sicher- 
heit  in  mobilen  Netzen  treffen.  Sicherlich  wird  in  fast  alien  denkbaren  Szenarien  unter 
Anwendung  von  mobilitatsorientierten  Protokollen  eine  Form  von  Authentifizierung  be- 
notigt.  Ebenso  gibt  es  zahlreiche  Anwendungen,  in  denen  Daten  fiber  drahtlose  Verbin¬ 
dungen  wie  auch  in  festverkabelten  Netzen,  unbedingt  verschliisselt  werden  mfissen,  in 
denen  der  Benutzer  sich  authorisieren  muss,  und  Vorgange  zentral  protokolliert  werden 
musssen.  Gleichzeitig  gibt  es  aber  Anwendungsbereiche  von  mobiler  Kommunikation,  in 
denen  das  nicht  erwunscht  ist,  zum  Beispiel  weil  diese  Mechanismen  negativen  Einfluss 
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auf  Leistung,  Quality  of  Service,  Effizienz  und  Geschwindigkeit  haben.  Gleichzeitig  hat  die 
Moglichkeit,  verschiedenste  Aspekte  von  AAA  innerhalb  eines  Micro-Mobility-Protokolls 
benutzen  zu  konnen,  mafigeblichen  Einfluss  auf  dessen  praktische  und  allgemeine  Anwend- 
barkeit.  Gleichzeitig  miissen  bei  all  den  Uberlegungen  auch  Effizienz  und  Geschwindigkeit, 
Abhangigkeiten  und  Managementaufwand  beriicksichtigt  werden.  Zum  Beispiel  waren  Ab- 
hangigkeiten  von  weiteren,  moglicherweise  weit  entfernten  AAA-Systemen  [8]  im  Bezug 
auf  Handoff- Geschwindigkeit  kaum  praktikabel,  in  dem  Fall  mfissten  schon  zum  Handoff- 
Zeitpunkt  die  notigen  Informationen  am  neuen  Accesspoint  verffigbar  sein.  Insbesondere 
durch  regelmafiige  Zellenwechsel  wird  deutlich  mehr  Kommunikation  zwischen  verschie- 
densten  Stellen  benotigt,  was  dem  Ziel  von  Micro-Mobility-Protokollen  zuwider  lauft.  Es 
miissen  also  Losungen  gefunden  werden,  die  fiber  das  AAA-Konzept  von  Mobile  IP  hin- 
ausgehen.  Ein  Ansatz  daffir  ist  das  „Fast  Session  Key“  Verfahren  [6],  das  im  Kapitel  4.4.3 
naher  beschrieben  wird. 


4.3.5  Das  Triangular  Routing  Problem 

Im  Zusammenhang  mit  Micro-Mobility  beschreibt  Triangular  Routing  einen  Ansatz,  un- 
notige  Wege  in  der  Kommunikation  zu  unterbinden.  Ffir  das  Mobile  IP  Protokoll  gibt 
es  dazu  eine  Erweiterung  zur  Routenoptimierung.  Wie  in  Abb.  4.5  kann  es  insbesondere 
in  Netzen,  in  denen  der  grofite  Teil  des  Datenverkehrs  innerhalb  der  Domane  bleibt,  zu 
solchen  ungfinstigen  Routen  ffihren.  In  der  Abbildung  sei  eine  Kommunikation  zwischen 
zwei  MNs  innerhalb  eines  Subnetzes  dargestellt.  MN1  sendet  an  MN2  fiber  dessen  HA, 
weil  er  ihn  in  seinem  Heimatnetz  adressiert.  Es  kann  nicht  davon  ausgegangen  werden,  dafi 
MNi  mit  einem  erweiterten  Mobilitatsprotokoll  arbeitet,  daher  kann  fiber  einen  Hinweis 
an  MNi  keine  Optimierung  stattfinden.  Zahlreiche  Micro-Mobility  Protokolle  haben  sich 
dieses  Problems  angenommen,  teilweise  explizit  in  ihre  Routingstrategie  aufgenommen, 
meist  jedoch  implizit  durch  deren  Konzept.  Das  Cellular  IP  Protokoll  nutzt  beispielsweise 
die  Heimatadressen  der  MNs  zur  Adressierung  innerhalb  der  Domane.  Das  Triangular 
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Routing  Problem  wird  damit  implizit  gelost.  Ein  Beispiel  fiir  die  explizite  Behandlung  ist 
das  Fast  HandofF  Protokoll.  Der  betriebene  Aufwand  steht  jedoch  zum  Nutzen  nur  dann 
in  einem  verniinftigen  Verhaltnis,  wenn  der  Grofiteil  der  Pakete  innerhalb  der  Domane 
bleibt. 


4.4  Die  bekanntesten  Protokolle 


Es  gibt  eine  Reihe  verschiedener  Konzeptstudien  und  Protokolle,  die  auf  unterschiedlichen 
Gewichtungen  der  Ansatze  basieren.  Diese  in  ihrer  Vielzahl  vorzustellen,  wiirde  die  Di¬ 
mension  dieser  Arbeit  weit  iibersteigen.  Statt  dessen  werden  hier  nur  einige  ausgewahlte 
Protokolle  vorgestellt,  die  charakteristisch  fiir  Uberlegungen  bei  Mikromobilitat  sind. 


4.4.1  Hierarchical  Mobile  IP 

Hierarchical  Mobile  IP  [10]  bildet  eine  natiirliche  Erweiterung  zum  Mobile  IP  Protokoll. 
Es  wurde  in  Zusammenarbeit  zwischen  Nokia  und  Ericsson  entwickelt  und  geht  von  einer 
Erweiterung  des  bekannten  Mobile  IP  Modells  aus,  basierend  auf  Hierachical  Tunneling. 
Dabei  wird  der  dem  HA  bekannte  FA  von  dem  Gateway  Foreign  Agent  (GFA)  des  jeweili- 
gen  Netzes  reprasentiert  (siehe  Abbildung  4.3).  Sobald  der  MN  das  Netz  betritt,  registriert 
er  sich  beim  HA  einmalig  mit  der  IP-Adresse  des  GFA.  Diese  globale  COA  bleibt  wah- 
rend  des  gesamten  Aufenthalts  in  der  Domane  konstant.  Registration  Messages  von  MNs 
erzeugen  Tunnel  zwischen  jeweils  benachbarten  FAs  nach  dem  Konzept  von  Hierarchical 
Tunneling.  Dementsprechend  kann  der  MN  lokal  fiber  seine  Heimatadresse  identifiziert 
werden,  da  nur  die  Knoten  mit  Tunnelendpunkten  involviert  sind. 

Zudem  kommt  ein  Paging-Konzept  in  Hierarchical  Mobile  IP  zur  Anwendung,  die  in  [11] 
als  Erweiterung  zu  Mobile  IP  vorgestellt  wurde,  und  nach  folgendem  Schema  funktioniert: 

Falls  der  MN  gerade  keine  Daten  sendet  oder  empfangt,  kann  er  in  den  Idle-Modus  wech- 
seln.  Wenn  der  MN  inaktiv  ist  (irn  Folgenden  IMN),  ist  die  genaue  Position  in  der  aktuellen 
Domane  nicht  mehr  bekannt.  Dafiir  werden  Paging  Foreign  Agents  (PFA)  eingefiihrt,  die 
jeweils  ihre  eigene  Paging  Area  verwalten.  Diese  sind  Unterbaume  der  FA-Hierarchie  mit 
dem  PFA  als  Wurzel.  Jeder  PFA  fiihrt  eine  Liste  aller  IMN  in  seiner  Paging  Area.  Der  PFA 
ist  dann  dafiir  zustandig,  an  den  IMN  adressierte  Datenpakete  zu  verwalten  und  nach  dem 
MN  zu  suchen.  Damit  das  moglich,  muss  der  IMN  regelmafiig  aktiv  werden,  um  solche 
Anfragen  oder  bei  einem  Zellenwechsel  auch  andere  Agent  Advertisements  zu  bemerken. 
Macht  er  dies  nach  festgelegten  Intervallen,  dann  spricht  man  von  „Time  Slot  Based  Pa¬ 
ging"  [11].  Der  Effekt  ist  zum  einen,  dass  der  MN  durch  Inaktivitat  Energie  spart,  zum 
anderen  konnen  durch  dieses  passive  Verhalten  Ressourcen  des  Netzes  geschont  werden, 
weil  ein  IMN  das  Netz  nicht  belegt.  Zwar  geht  dies  in  Abhangigkeit  vom  Paging  Inter- 
vall  zu  Lasten  der  Reaktionszeit,  andererseits  ist  diese  bei  dem  Aufbau  einer  Verbindung 
in  mobilen  Netzen  im  Gegensatz  zur  effektiven  Energieverwaltung  von  untergeordneter 
Bedeutung. 
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4.4.2  Fast  Handoff  und  Proactive  Handoff 

Basierend  auf  den  Verbesserungen  durch  Hierarchical  Mobile  IP  wurden  im  Fast  Han¬ 
doff  Protokoll  von  Ericsson  zwei  weitere  Probleme  behandelt:  Im  Hinblick  auf  Realtime- 
Anwendungen  wie  VoIP  sollte  das  Handoff-Management  optimiert  werden,  zum  anderen 
wollte  man  das  Triangular  Routing  Problem  (siehe  4.3.5)  innerhalb  der  Domane  losen. 

Das  Hierachical  Mobile  IP-Protokoll  optimiert  die  Erkennung  von  Zellenwechseln  nicht. 
Im  Gegensatz  dazu  erwagt  Fast  Handoff  die  Moglichkeit  der  Interaktion  mit  der  Radio- 
Schicht,  um  sich  beim  neuen  FA  registrieren  zu  konnen,  bevor  der  Handoff  iiberhaupt 
stattgefunden  hat.  Stets  werden  auf  Schicht  2  Informationen  fiber  die  umliegenden  Netze 
gesammelt.  Auf  Grundlage  dieser  Daten  ist  es  moglich,  Zellenwechsel  vorrauszusagen  und 
das  Protokoll  dariiber  zu  informieren.  In  [4]  wird  diese  Interaktion  mit  dem  Radio  Inter¬ 
face  als  SHRT,  Strong  handoff  Radio  Trigger  bezeichnet.  Diese  wird  von  alien  beteiligten 
Knoten  registriert  und  informiert  die  beteiligten  iiber  den  MN,  den  alten  und  neuen  FA. 
In  Fast  Handoff  ist  der  MN  somit  in  der  Lage,  sich  iiber  den  alten  FA  bereits  beim  neuen 
FA  zu  registireren,  wie  in  Bild  4.6  a)  dargestellt.  Die  Registrierung  lauft  in  vier  Schritten 
ab: 


1.  MN  empfangt  Informationen  iiber  den  bevorstehenden  Zellenwechsel,  informiert 
durch  einen  Trigger  von  Schicht  2  und  sendet  Request  an  FAneu 

2.  FAneu  sendet  ein  Agent  Advertisement  iiber  FAait  zum  MN 

3.  Der  MN  registriert  sich  bei  FAneu  iiber  den  alten  Radio  Link.  Mobile  IP  Bicasting 
kann  zudem  verwendet  werden,  um  Paketverluste  zu  vermeiden  (optional) 

4.  Wechsel  des  MN  zum  neuen  WIPPOA 


Hinter  Proactive  Handoff  [13]  steht  ein  ahnliches  Prinzip,  mit  dem  Unterschied,  dass  der 
IP  Handoff  nicht  vom  MN,  sondern  von  den  beiden  FAs  initiiert  wird  (vgl.  Abbildung  4.6 
b)). 

1.  FAneu  bekommt  ein  SHRT  und  sendet  eine  Registrierungsanfrage  zum  GFA,  der 
daraufhin  ein  Bicasting  zu  FAait  und  FAneu  einleitet 

2.  FAneu  sendet  ein  Agent  Advertisement  iiber  FAait  zum  MN 

3.  MN  beginnt  eine  normale  Registrierung  beim  neuen  FA 


Das  Zeitfenster,  in  dem  der  MN  nicht  erreichbar  ist,  wird  demnach  auf  die  Dauer  des 
Schicht  2  Handoffs  beschrankt. 
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Bei  neuem  FA  fiber  FA®  regislrieren  Beim  GFA  durch  FA,1(,U  registrieren  lassen 

Abbildung  4.6:  Handoff  Mechanismen  fiir  a)  Fast  Han  doff  und  a)  Proactive  Handoff  [4]. 

4.4.3  Cellular  IP 

Das  Cellular  IP  Protokoll  hat  eine  besondere  Stellung  unter  den  Micro-Mobility  Protokol- 
len.  Es  verzichtet  vollkommen  auf  Tunneling  und  Adresskonversion,  indem  es  das  bekannte 
IP-Routing  innerhalb  einer  Domane  ersetzt.  Es  wird  durch  ein  Netz  sogenannter  Cellular 
IP  Router  (CIPR)  ersetzt,  die  auch  fremde  IPs  im  Netz  korrekt  routen  konnen  (All-IP 
Netzwerk).  Ursprung  dieses  Ansatzes  war  folgende  Uberlegung:  Man  nehme  ein  einfaches 
Netz  aus  Accesspoints,  Switches  und  einigen  MNs.  Die  Lernfahigkeit  von  Ethernetswitches 
wird  darin  zur  MN-Suche  benutzt.  Solch  ein  Konzept  ist  preiswert,  einfach  und  effizient. 
Leider  gibt  es  keine  verniinftigen  Moglichkeiten,  um  dieses  Netz  nach  zuvor  vorgestellten 
Ansatzen  zu  optimieren.  Cellular  IP  nutzt  aber  nach  diesem  Konzept  Datenpakete  zum 
Aktualisieren  von  Locationtables,  entweder  auf  Schicht  2  oder  3.  Cellular  IP  Nodes  iiber- 
nehmen  diese  Verwaltung,  das  sind  entweder  einfache  Switches  (Schicht  2)  oder  Cellular 
IP  Router  (Schicht  3).  Es  wird  behauptet,  ein  Cellular  IP  Netzwerk  aus  kostengiinstigen 
Switches  fiir  mehrere  tausend  Benutzer  noch  effizient  realisieren  zu  konnen  [3,  S.  179].  Das 
ist  insbesondere  dann  interessant,  wenn  es  sich  um  die  Realisierung  von  Pico-Netzen  han- 
delt,  beispielsweise  um  die  drahtlose  Vernetzung  von  Campus-Universitaten,  in  denen  eine 
komplexe  Hierarchie  von  Routern  unnotig  erscheint.  Zu  einem  komplexeren  CIP-Netz  ge- 
horen  folgende  Komponenten:  Die  Basisstationen  sind  zum  einen  als  Accesspoints  der  MNs 
zu  sehen,  gleichzeitig  sind  es  meist  selbst  Cellular  IP-Router.  Alle  Basisstationen  einer  Do¬ 
mane  sind  mit  dem  Internet  fiber  einen  gemeinsamen  Gateway  verbunden,  der  als  eiziger 
FA-Funktionen  besitzen  mufi.  Wahrend  sich  der  MN  innerhalb  des  Netzes  befindet,  nutzt 
er  die  IP  des  Gateways  als  seine  Care-Of- Address.  Ausserhalb  des  Gateways  gilt  wieder 
das  Prinzip  von  Mobile  IP.  Die  am  Gateway  ankommenden  Pakete  werden  entkapselt  und 
im  Cellular  IP  Netz  versandt,  wobei  der  MN  uber  seine  Heimatadresse  identifiziert  wird. 
Fur  die  korrekte  Zustellung  der  Pakete  sind  die  hierarchisch  angeordneten  CIP-Router 
zustandig.  Die  Aktualisierung  der  „Location  Tables"  erfolgt  durch  Snooping  normaler  IP- 
Pakete,  solange  der  MN  sich  nicht  bewegt.  Besondere  Registration  Messages  werden  nur 
dann  gebraucht,  wenn  der  MN  sich  zum  ersten  Mai  registriert  oder  seinen  WIPPOA  an- 
dert.  Allerdings  ist  es  theoretisch  denkbar,  dab  der  MN  langere  Zeit  nicht  sendet,  obwohl 
er  de  facto  erreichbar  ist.  Dies  ware  z.B.  bei  einem  Videostream  per  UDP  der  Fall.  Daher 
werden  auch  in  diesem  Protokoll  regelmassige  Registration  Messages  gesendet,  wobei  de- 
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ren  Intervall  konsequenterweise  kleiner  sein  muB  als  die  Lebenszeit  der  Rout ingeintr age. 
Zusatzlich  werden  vom  Gateway  regelmassige  Beacons  innerhalb  des  Netzes  gebroadcas- 
tet.  Jeder  CIP  Knoten,  der  diesen  empfangt,  sendet  ihn  auf  alien  anderen  Schnittstellen 
weiter,  abschliefiend  kennt  jeder  Knoten  den  Uplink,  namlich  das  Interface  zum  Gateway. 
Durch  dieses  Verfahren  wird  theoretisch  eine  beliebige  Erweiterbarkeit  des  Netzes  mog- 
lich,  die  nahezu  ohne  Administrationsaufwand  auskommt.  Neben  diesem  Konzept  wird 
in  Cellular  IP  klassisches  Paging  benutzt.  Wenn  der  MN  inaktiv  ist,  mufi  er  bei  einem 
Wechsel  der  Paging  Area  ein  Paging  Packet  senden.  Dieses  wird  zum  Gateway  geroutet 
und  muB  irgendwann  den  Knoten  passieren,  der  den  Paging  Cache  fur  diesen  MN  besitzt, 
damit  dieser  aktualisert  werden  kann.  Das  hat  zur  Folge,  dafi  das  Netz  eine  Baumstruktur 
besitzen  muss. 

Handoff 

In  Cellular  IP  werden  zwei  Arten  von  Handoff  unterschieden,  mit  jeweils  unterschiedlicher 
Gewichtung  von  Paketverlust,  Verzogerung,  Aufwand  und  Netzbelastung:  Beide  Losungen 
beriicksichtigen  die  Moglichkeit,  per  SHRT  einen  L2-getriggerten  Handoff  beginnen  zu 
konnen. 

Hard  Handoff  verzichtet  auf  aufwendige  Kommunikation  zwischen  den  Beteiligten  und 
nimmt  Paketverluste  in  Kauf.  Wahrend  der  MN  mit  einer  Basisstation  verbunden 
ist,  sucht  er  nach  weiteren  mit  besserer  Signalstarke  und  initiiert  gegebenenfalls  einen 
Handoff.  Als  erstes  wird  also  der  Accesspoint  gewechselt  und  ein  „Route  Update 
Packet"  in  Richtung  Gateway  gesandt.  Geht  man  zur  Vereinfachung  davon  aus, 
daB  die  Zeit  fur  den  Wechsel  des  Accesspoint  t Handoff  zu  vernachlassigen  ist,  dann 
beschrankt  sich  die  Dauer  des  Paketverlustes  auf  t Handover  =  tcR,neu  +  tcR,aiti  wie  in 
der  Abbildung  4.7  dargestellt:  Alle  Pakete  gehen  verloren,  die  den  Crossover  Node 
(CR)  vom  Zeitpunkt  des  Handoffs  bis  zur  Ankunft  des  „Route  Update  Packets" 
durchlaufen  haben,  und  alle,  die  sich  zwischen  CR  und  MN  befanden.  Der  CR  ist 
dabei  der  Knoten,  an  dem  sich  die  alte  und  neue  Route  kreuzen,  also  im  schlechtesten 
Fall  der  Gateway.  Sicherlich  ist  diese  Zeitspanne  t Handover  viel  kleiner  als  t^A,  die 
Zeit,  die  im  Abschnitt  4.2.2  als  Verzogerung  durch  die  Registrierung  beim  Home 
Agent  fiir  Mobile  IP  definiert  wurde.  Dadurch  wird  die  Anzahl  der  Paketverluste 
bereits  in  diesem  Ansatz  stark  reduziert. 

Semisoft  Handoff  verfolgt  das  Ziel,  Paketverluste  vollstandig  zu  vermeiden.  Mithilfe 
sogenannter  „Semisoft  Packets"  werden  die  Routingeintrage  zur  neuen  Basisstati¬ 
on  bereits  vor  dem  eigentlichen  Handoff  erzeugt.  Dazu  wird  ein  solches  „Semisoft 
Packet"  liber  den  neuen  Accesspoint  gesendet,  wobei  der  MN  danach  sofort  wieder 
auf  die  alte  Basisstation  zuriickschaltet.  Aufgrund  des  besonderen  Pakets  wird  der 
CR  daraufhin  alle  ankommenden  Pakete  an  die  alte  und  neue  Base  Station  senden 
(Bicasting).  Nach  einem  „Semisoft  Delay"  wird  dann  ein  normaler  Handoff  durch- 
gefiihrt  und  das  Bicasting  aufgehoben.  Damit  sind  Paketverluste  jedoch  noch  nicht 
behoben.  Es  kann  durchaus  passieren,  dafi  tcR,ait  >  tcR,neu  ist.  Dann  kommen  die 
Pakete  am  neuen  Accesspoint  an  ,  bevor  der  MN  sie  am  alten  empfangen  kann.  Selbst 
ein  zeitloser  Handoff  {tnandoff  - *  0)  ware  nicht  schnell  genug,  um  diese  Pakete  am 
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Abbildung  4.7:  Ein  Handoff  mit  Cellular  IP  iiber  den  Crossover-Node 

neuen  AP  noch  zu  empfangen.  Dieses  Problem  wird  gelost,  indem  die  Pakete  auf 
der  neuen  Route  gebremst  werden.  Dazu  wird  ein  konstanter  Buffer  fur  ticr  Pakete 
eingerichtet,  der  die  Pakete  bis  zum  Abschluss  des  Handoffs  verzogert.  Der  Wert  fur 
ncR  bestimmt  sich  dabei  einerseits  aus  bekannten  Werten  fur  das  jeweilige  Netz, 
z.B.  anhand  der  explizit  zu  bestimmenden,  maximal  moglichen  Lange  eines  Weges 
auf  dem  Baum  der  CIP-Hierarchie  ausgehend  vom  jeweiligen  CR,  andererseits  aus 
den  Prioritaten  zwischen  Paketverlust  und  Delay,  da  ucr  bei  jedem  Handoff  am  CR 
konstant  bleibt  und  somit  stets  auftritt. 


Session  Keys 

Auch  in  Cellular  IP  is  es  von  elementarer  Bedeutung,  die  eintreffenden  Location  Update 
Pakete  von  jedem  MN  zu  authentifizieren,  damit  nicht  falschlicherweise  fremde  Quellen 
die  CIP-Routing-Informationen  andern  konnen.  Gefalschte  Pakete  konnen  auf  einfachste 
Art  und  Weise  Angriffe  auf  das  Netz  darstellen.  Daher  dlirfen  nur  authentifizierte  Pakete 
Routinginformationen  loschen,  wahrend  normale  Pakete  bereits  bestehende  ohne  weiteres 
aktualisieren  dlirfen.  Mithilfe  eines  Session  Keys  wird  das  Problem  der  Authentifizierung 
sicher  und  effizient  gelost.  Ein  solcher  Schliissel  berechnet  sich  bei  CIP  folgendermaBen: 

•  Die  IP-Adresse  IPmn ,  also  die  Heimatadresse  des  MN 

•  Eine  Zufallszahl  Rmn,  die  dem  jeweiligen  MN  bei  der  ersten  Registrierung  innerhalb 
des  Netzes  zugeteilt  wird 
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•  Einen  privaten  Schliissel  Kcip,  der  nur  den  Basisstationen  des  Cellular  IP  Netzwer- 
kes  bekannt  ist 

Daraus  berechnet  sich  der  Session  Key  mit  Hilfe  einer  MD5  Hashfunktion  zu  Keysession  := 
MD5(IPmn,Rmn,Kcip)-  Dieser  Session-Key  wird  dem  MN  zugeordnet,  sobald  er  sich 
dem  Netzwerk  anschliefit.  Alle  „Controll-Pakets“,  die  zum  Erstellen  einer  neuen  Route 
zum  MN  benutzt  werden  mussen,  beinhalten  den  Zufallsschliissel  Rmn  und  ei'nen  „Ti- 
mestamp“,  um  Replay  zu  verhindern.  Im  Payload  des  jeweiligen  Pakets  ist  ein  „Message 
Authentication  Code*1  enthalten,  der  sich  aus  dem  Session  Key,  einem  Zeitstempel  und 
dem  Paketinhalt  berechnet.  Somit  konnen  die  Stationen  die  Echtheit  der  eintreffenden 
Pakete  priifen,  ohne  mit  aussenstehenden  Instanzen  kommunizieren  zu  mussen,  indem  sie 
selbst  den  entsprechenden  Session  Key  aus  den  im  jeweiligen  Paket  enthaltenen  Rmn  und 
der  IP-Adresse  mit  Kcip)  berechnen  und  daraufhin  den  Inhalt  der  Nachricht  verifizieren 
konnen.  Zusatzliche  Sicherheit  kann  gewonnen  werden,  wenn  der  private  Netzwerkschliis- 
sel  Kcip  innerhalb  des  Netzes  regelmafiig  geandert  wird. 


4.4.4  Hawaii 

Das  Handoff- Aware  Wireless  Access  Internet  Infrastructure  Protokoll,  kurz  Hawaii,  wurde 
von  Lucent  Technologies  entwickelt.  Es  agiert  als  Micro-Mobility  Protokoll  in  einer  ge- 
schlossenen  Domane.  Zwar  ist  es  in  seinen  Fahigkeiten  und  Optimierungsansatzen  ahnlich 
zu  Cellular  IP,  dennoch  gibt  es  einige  konzeptionelle  Unterschiede.  Auch  Hawaii  verzichtet 
auf  Tunneln  innerhalb  der  Domane,  allerdings  wird  dem  MN  beim  Betreten  eine  COA  per 
DHCP  zugewiesen.  Diese  bleibt  konstant,  solange  sich  der  MN  innerhalb  dieses  Netzes  be- 
wegt.  Mit  der  „Path  Setup  Powerup  Message**,  also  der  ersten  Registrierung  innerhalb  des 
Netzes,  wird  eine  Nachricht  zum  „Domain  Root  Router“(DRR),  gesendet.  Dieser  stellt  die 
gemeinsame  Schnittstelle  des  Netzes  dar  und  ist  der  Tunnelendpunkt  fur  Mobile  IP.  Alle 
Router  auf  dem  Weg  zum  DRR  nehmen  die  COA  des  MN  in  ihre  Routing-Tabelle  auf. 
Sobald  der  DRR  die  Nachricht  bekommt,  wird  ein  Acknowledge  auf  dem  soeben  erstellten 
Weg  zum  MN  zuriickgesandt  und  die  Registrierung  beim  HA  durchgefiihrt.  Alle  anderen 
Router  innerhalb  der  Domane  kennen  die  IP  des  MN  nicht  und  werden  daher  alle  fur  den 
MN  bestimmten  Pakete,  z.B.  von  anderen  MNs  in  Richtung  DRR  senden.  Path  Setup 
Refresh  Messages  sorgen  fur  regelmassige  Aktualisierungen  der  Pfade,  wahrend  Update 
Messages  bei  jedem  Handoff  benutzt  werden,  um  neue  Routingeintrage  zu  erstellen. 

Hawaii  bietet  verschiedene  Strategien,  sogenannte  „Path  Setup  Schemes**  an,  mit  unter- 
schiedlichen  Gewichtungen,  Paket verluste  und  Verzogerungen  zu  minimieren  und  den  Ad- 
ministrationsaufwand  gering  halten  zu  wollen.  Diese  unterteilen  sich  grundsatlich  in  zwei 
Gruppen: 


•  Forwarding  Path  Setup  Schemes  leiten  die  Pakete  wahrend  des  Handovers  von 
der  alten  zur  neuen  Basisstation  weiter,  bevor  der  Crossover  Router  seinen  Eintrag 
aktualisiert  und  somit  direkt  an  den  MN  routet.  Hawaii  unterscheidet  dabei  zwei 
Ansatze: 
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(0)  IPmn  ->  B 
(3)  \Pm  ->  C 


(0)  IPMN  ->  B 
(3)IP«*->C 


Abbildung  4.8:  Forwarding  Path  Setup  Schemata  MSF  (links)  und  SSF  (rechts),  aus  [7] 


Multiple  Stream  Forwarding  (MSF)  funktioniert  folgendermafien:  Nach  dem  Han- 
doff  sendet  der  MN  eine  „Path  Setup  Update  Message11  an  die  alte  Basisstation, 
mit  der  IP  der  neuen.  Sobald  BSait  das  Paket  empfangen  hat,  wird  das  Inter¬ 
face  gesucht,  unter  dem  es  BSneu  erreichen  kann  und  andert  den  Routingeintrag 
far  den  MN  entsprechend  (siehe  Abbildung  4.8  a)).  Er  sendet  die  Updatenach- 
richt  nun  auf  dem  Pfad  quasi  zuriick,  namlich  zum  Router i .  Dieser  verfahrt 
ebenso  und  sendet  die  Nachricht  weiter.  Sobald  die  Nachricht  BSneu  erreicht, 
bekommt  der  MN  eine  Bestatigung.  Es  ist  nicht  unbedingt  offensichtlich,  dafi 
bei  diesem  Verfahren  mehrere  Datenstrdme  entstehen,  die  zu  falscher  Reihen- 
folge  der  Pakete  fiihren  konnen  und  dem  Schema  seinen  Namen  gegeben  hat. 
Die  Entstehung  soli  anhand  der  Verbindung  zwischen  Routeri  und  BSait  er- 
lautert  werden.  Nachdem  BSait  das  Paket  2  abgeschickt  hat,  passieren  noch 
einige  Pakete  Routeri.  Durch  Paket  2  andert  Routeri  seine  Routingtabelle, 
und  alle  ankommenden  Pakete  werden  zu  Interface  A  geleitet.  Erst  danach 
kommen  jedoch  falsch  geroutete  Pakete  an  Interface  C  an,  die  anschlieBend  - 
in  der  falschen  Reihenfolge  -  iiber  A  weitergeleitet  werden.  Da  dieser  Effekt  an 
jedem  Knoten  bis  zum  CR  auftritt,  kann  dies  negative  Folgen  fur  VoIP  oder 
auch  TCP-Verbindungen  haben.  Paketverluste  werden  so  jedoch  vollstandig 
vermieden. 

Single  Stream  Forwarding  (SSF)  soil  dieses  Problem  beheben.  Dazu  fiihrt  einen 
neuen  Begriff,  das  interface  Based  Forwarding11  ein,  uni  die  korrekte  Paketrei- 
henfolge  der  umgeleiteten  Pakete  einzuhalten,  ohne  dafiir  Tunnel  nutzen  zu 
mussen.  Eine  normale  Routingfunktion  bildet  eine  IP-Adresse  auf  ein  Interface 
ab  (IP  — ►  Inter faceout).  Die  hier  zum  tragen  kommende  Erweiterung  des  Rou- 
tingverfahrens  entspricht  der  Funktion  Inter  facesin  x  IP  — >  Inter  faceout  und 
ahnelt  in  ihrem  Effekt  der  erganzten  Routenoptimierung  bei  Mobile  IP.  Mit 
dieser  Erweiterung  kann  ein  einzelner  Stream  der  von  BSait  zu  BSneu  weiter- 
geleiteten  Pakete  realisiert  und  Paketverluste  verhindert  werden.  Allerdings  ist 
der  Aufwand  fur  diese  Alternative  relativ  hoch,  sodaB  sie  sich  bei  den  wenigsten 
Handoffszenarien  lohnt. 
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•  Nonforwarding  Path  Setup  Schemes  leiten  die  Pakete  bereits  am  Crossover- 
Router  um,  ohne  sich  selbst  um  die  Vermeidung  von  Paketverlusten  durch  Forwar¬ 
ding  zu  kiimmern.  Diese  Paketverluste  werden  entweder  in  Kauf  genommen,  oder 
konnen  durch  parallele  Kommunikation  mit  BSalt  und  BSneu  abgefangen  werden. 
Letzteres  ware  durchaus  denkbar  fur  CDMA-basierte  Kommunikationssysteme  oder 
WaveLAN  [7].  Zwei  Schemata  realisieren  diesen  Ansatz: 

Das  Unicast  Nonforwarding  Schema  (UNF)  setzt  voraus,  daB  ein  MN  kurzzei- 
tig  mit  der  alten  und  neuen  Basisstation  kommunizieren  kann.  Dazu  sendet  der 
MN  eine  Update  Message  an  die  neue  Basisstation,  die  daraufhin  einen  Eintrag 
fur  den  MN  erzeugt.  BSneu  sendet  diese  Nachricht  weiter  zum  nachsten  Rou¬ 
ter  auf  dem  Weg  zu  BSait  ■  Falls  letztere  das  Paket  empfangt,  wird  direkt  ein 
Acknowledge  an  den  MN  gesandt,  da  alle  bis  dato  vorhandenen  Routingein¬ 
trage  fur  den  MN  geandert  wurden.  Offensichtlich  findet  hier  das  Update  der 
Routingeintrage  bereits  auf  dem  „Hinweg“  statt,  sodafi  die  Pakete  schneller  auf 
dem  neuen  Weg  geroutet  werden.  Dementsprechend  ist  ein  Forwarding  noch 
ankommender  Pakete  nicht  moglich,  weil  das  Route  Update  Paket  erst  nach 
diesen  an  der  alten  BS  ankommt.  Durch  das  fehlende  Forwarding  ist  dieses 
Konzept  unter  vorgenannten  Bedingungen  optimal. 

Das  Multicast  Nonforwarding  Schema  ist  prinzipiell  identisch  zu  UNF,  mit 
dem  Unterschied,  dafi  der  CR  Pakete  kurzzeitig  multicastet,  um  Paketverluste 
in  Fallen  zu  verhindern,  in  denen  der  MN  nur  jeweils  von  einer  BS  emfan- 
gen  kann.  Dieses  Schema  ist  entsprechend  fur  „Time  Division  Multiple  Access11 
Netzwerke  gedacht. 


Transparenz  des  Hawaii-Protokolls 


Dass  die  Micro-Mobility-Protokolle  gegeniiber  dem  Mobile  IP  Protokoll  nach  auBen  trans¬ 
parent  sein  miissen,  wurde  bereits  vorab  herausgearbeitet.  Das  Hawaii-Protokoll  ermog- 
licht  es  u.a.  sogar,  daB  Hawaii  auch  fur  den  MN  transparent  bleiben  kann.  Um  dies  zu 
realisieren,  muss  die  jeweilige  Basisstation  Mobile  IP  Nachrichten  in  Hawaii-konforme 
Nachrichten  iibersetzen.  Der  MN  sende  eine  Mobile  IP  Registration  Message,  um  sich 
beim  HA  zu  registrieren.  Die  entsprechende  Basisstation  ubersetzt  dieses  Paket  in  eine 
Path  Setup  Powerup  Message,  die  einen  oben  beschriebenen  Registrierungsprozess  aus- 
lost.  Desweiteren  wird  der  MN  regelmassige  Advertisement  Request  absenden,  um  nach 
neuen  FAs  zu  suchen.  Aus  diesen  erzeuge  die  Basistation  eine  „Path  Setup  Refresh  Messa¬ 
ge11,  falls  ihr  der  MN  bereits  bekannt  ist.  Damit  werden  die  Routingeintrage  innerhalb  der 
Domane  aktualisiert.  Falls  die  Basisstation  den  MN  nicht  kennt,  oder  eine  Nachricht  auf 
einem  anderen  Interface  erwartet  hatte,  muB  eine  „Path  Setup  Update  Message11  gesendet 
werden,  um  neue  Routingeintrage  zu  erstellen.  Der  MN  bekommt  davon  jedoch  nichts  mit. 
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Ethernet  Switch 

Cellular  IP 

Hawaii 

Hierarchical  MIP 

MRP  Schicht 

L2 

L3 

L3 

„L3.5“ 

MRP 

Alle  Switches 

CIP  Knoten 

alle  Router 

alle  FAs 

MN  ID 

•MAC 

Home  IP 

COA 

Home  IP 

Ohne  Wirkung 

- 

Switches 

Switches 

Router 

MRP  „ID“ 

(LI) 

MAC 

MAC 

IP 

Updates 

implizit 

(implizit) 

explizit 

explizit 

Tabelle  4.1:  Ein  Vergleich  bekannter  Micro  Mobility  Protokolle 


4.5  Vergleich  der  Protokolle 


4.5.1  Konzepte 


Ganz  offensichtlich  gibt  es  viele  Ahnlichkeiten  in  der  Funktionsweise  von  Micro  Mobility 
Protokollen.  Im  Detail  ergeben  sich  jedoch  zahlreiche  charakteristische  Unterschiede  wie 
die  Identifizierung  der  MNs,  die  Struktur  und  Verteilung  der  „Location  Databases",  sowie 
die  Moglichkeiten  der  Datenbankaktualisierung  [8].  Solche  Eintrage  sind  mit  Timern  ver- 
sehen,  und  miissen  durch  regelmassige  Nachrichten  aktualisiert  werden.  Das  kann  implizit 
durch  das  Snooping  normaler  Pakete  geschehen,  oder  explizit  durch  besondere  Nachrich¬ 
ten.  Fur  ankommende  Pakete  bildet  diese  Serie  von  „next-hop“  Eintragen  den  Weg  zum 
aktuellen  WIPPOA.  Dafiir  wird  an  Knoten  des  Netzwerks  die  Zieladresse  ausgelesen,  mit 
der  eigenen  Liste  verglichen  und  zum  nachstzen  Knoten  weitergeleitet.  Diese  Knoten  wer¬ 
den  im  Weiteren  als  MRP,  Mobile  Routing  Points  bezeichnet.  Im  Falle  von  Hierarchical 
Mobile  IP  gibt  es  nur  einige  explizite  MRPs,  namlich  die  FAs.  Diese  sind  durch  Tun¬ 
nel  miteinander  verbunden  und  entkapseln  die  Pakete  nur  kurzzeitig,  um  als  Router  zu 
fungieren,  indem  sie  den  Adressaten  auslesen  und  die  Pakete  daraufhin  weiter  tunneln. 
HMIP  wird  daher  als  ein  „Schicht  3.5“  Protokoll  bezeichnet.  Auch  Router  zwischen  den 
FAs  beeinflussen  die  Weiterleitung  der  Pakete  nicht  (siehe  auch  Tabelle  4.1).  Mit  dieser 
IP-in-IP  Kapselung  enthalt  das  Paket  stets  die  IP  des  MN  und  als  Absender  und  Empfan- 
ger  die  IPs  der  beiden  beteiligten  FAs.  Bei  Hawaii  und  CIP  wird  kein  Tunneln  benutzt. 
Statt  dessen  ist  diese  Information  in  den  Paketen  implizit  enthalten,  wobei  Cellular  IP 
als  Identifikation  der  MNs  die  Heimatadresse  benutzt.  Dies  fiihrt  dazu,  dah  zwischen  den 
CIP  Routern  keine  „normalen“  L3-Knoten  existieren  diirfen,  da  diese  mit  der  IP  des  MNs 
nichts  anfangen  konnen  und  das  Paket  zuriick  in  Richtung  Gateway  senden  wiirden.  In 
der  Tabelle  4.1  werden  daher  nur  jene  Knoten  als  „Ohne  Wirkung“  bezeichnet,  die  keinen 
Einfluss  auf  die  Zustellung  der  Pakete  haben.  Alle  soeben  genannten  Merkmale  hangen 
unmittelbar  von  der  Entscheidung  ab,  auf  welcher  Schicht  das  Protokoll  agieren  soil.  Ein 
weiterer  in  der  Tabelle  aufgefiihrter  Unterschied  ist  die  Realisierung  der  Routing  Updates. 
Diese  Entscheidung  ist  von  den  vorhergehenden  vollkommen  unabhangig.  Cellular  IP  ver- 
sucht  hier,  eine  implizite  Signalisierung  durchzusetzen,  um  ohne  Verwaltungsnachrichten 
auszukommen.  Um  die  Protokolle  zu  strukturieren,  kdnnen  sie  auch  wie  in  der  Tabelle  4.2 
charakterisiert  werden. 
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OSI-Schicht 

Update  durch 

Pakete  Nachrichten 

2 

Ethernet  Switch 

3 

Cellular  IP  Hawaii 

3.5 

HMIP 

Tabelle  4.2:  Matrix  zur  Charakterisierung  von  Protokollen 


MN 


Abbildung  4.9:  Das  Netzwerk  der  Simulation 

4.5.2  Simulation 


Es  ist  nicht  einfach,  Protokolle  zu  vergleichen,  die  auf  so  unterschiedlichen  Annahmen 
und  Vorraussetzungen  basieren  wie  das  Hierarchical  Mobile  IP  Protokoll,  Hawaii  und 
Cellular  IP.  Verschiedenste  Quellen  haben  in  Versuchsaufbauten  die  Leistungsfahigkeit 
der  einzelnen  Protokolle  herauszustellen  versucht.  In  einer  Veroffentlichung  der  IEEE  [7] 
stellt  der  Author  Dr.  R.  Ramjee  das  Hawaii  Protokoll  vor,  um  es  in  einer  Simulation 
anschlieBend  mit  dem  Mobile  IP  Protokoll  zu  vergleichen  und  die  Unterschiede  von  MSF, 
SSF,  UNS  und  MNF  herauszustellen.  Andrew  T.  Campbell,  Professor  an  der  Columbia 
University,  New  York,  richtete  seinen  Artikel  zum  Thema  Internet  Micromobility  [6]  auf 
das  Cellular  IP  Protokoll  aus,  dessen  Entwicklung  er  mafigeblich  vorantrieb.  Dabei  legte 
er  in  seinem  Versuchsaufbau  eine  etwas  andere  Struktur  des  Netzwerkes  fest  als  Dr.  R. 
Ramjee.  DaB  die  Festlegung  des  zugrundeliegende  Versuchsaufbaus  nicht  trivial  ist,  liegt 
nahe.  Um  in  dieser  Arbeit  die  drei  oben  genannten  Protokolle  vergleichen  zu  konnen,  muB 
ein  Aufbau  gefunden  werden,  der  alien  Protokollen  gleichmassig  gerecht  werden  kann.  Das 
ist  nicht  ohne  weiteres  moglich.  Daher  werden  in  dieser  Arbeit  die  Ergebnisse  weniger, 
dafiir  moglichst  unterschiedlicher  Simulationen  aus  dem  Artikel  „Comparison  of  IP  Micro- 
Mobility  Protocols"  [8]  vorgestellt  und  mit  eigenen  Uberlegungen  erweitert. 
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CIP 

Hawaii 

HMIP 

Wo 

Gateway 

DRR 

GFA 

w 

CIP  Nodes 

Hawaii  Router 

Router 

APi 

CIP  Nodes 

Hawaii  Router 

FA 

Tabelle  4.3:  Die  Knoten  der  einzelnen  Simulationen 


Paketverluste  durch  Handoff 


Crossover  Distance 


Hierarchical  M1P 


Cellular  IP 


Hawaii 


Abbildung  4.10:  UDP  Paketverluste  wahrend  des  Handoffs,  entnommen  aus  [8] 


Im  ersten  Versuch  sollen  die  drei  Protokolle  im  Bezug  auf  Paketverluste  wahrend  des  Han¬ 
doffs  untersucht  werden,  basierend  auf  der  Netztopologie  aus  Abbildung  4.9.  Verglichen 
werden  CIP  Hard  Handoff  und  Hawaii  UNF  mit  Hierarchical  Mobile  IP  basierend  auf 
einem  UDP-Datenstrom  von  100  Packets/s  zwischen  CN  und  MN.  Dabei  wurde  die  Be- 
wegung  des  MN  im  Versuchsaufbau  so  simuliert,  das  jeweils  eine,  zwei  und  drei  Spriinge 
zwischen  den  APs  und  dem  CN  waren,  also  Wechsel  zwischen  AP\  — >  AP2,  AP2  — > >  -4/ 3 
und  AP3  — *  AP4.  Dabei  wurden  die  durchschnittlichen  Ergebnisse  nach  100  Versuchen 
im  Diagramm  4.10  dargestellt.  Es  fallt  auf,  dafi  die  Verluste  fiir  HMIP  unverandert  hoch 
bleiben,  wahrend  sie  bei  Cellular  IP  und  Hawaii  jeweils  sehr  ahnlich  sind,  aber  mit  gerin- 
gerer  Entfernung  zum  Crossover  Node  sinken.  Das  zweite  Ergebnis  iiberrascht  nicht,  da 
die  Handoffverzdgerung  bei  CIP  und  Hawaii  mafigeblich  vom  Anstand  zum  CR  abhangt. 
Sobald  der  Routingeintrag  in  diesem  Knoten  aktualisiert  wurde,  werden  die  Pakete  in 
beiden  Protokollen  wieder  korrekt  weitergeleitet.  Anders  verhalt  es  sich  bei  HMIP,  weil 
die  Routingeintrage  erst  dann  korrigiert  werden,  wenn  die  neue  Registration  Message  den 
GFA  erreicht  hat.  Der  Abstand  zum  GFA  ist  in  der  Simulation  jedoch  konstant,  und  somit 
auch  die  duchschnittlich  verlorenen  Pakete.  HMIP  hat  in  diesem  Zusammenhang  also  ein 
konzeptionelles  Defizit,  denn  es  kann  von  moglicherweise  geringem  Abstand  zum  CR  nicht 
profitieren. 

Es  wurde  festgestellt,  dafi  CIP  und  Hawaii  sich  in  dem  Versuchsaufbau  sehr  ahnlich  ver- 
halten  haben.  Diese  Ahnlichkeit  geht  verloren,  wenn  nicht  mehr  von  einer  Baumstruktur 
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Abbildung  4.11:  Eine  suboptimale  Route  nach  mehreren  Handoffs 


des  Netzes  ausgegangen  wird,  wie  es  zur  Vereinfachung  im  Versuchsaufbau  (Abb.  4.9) 
angenommen  wurde.  Wenn  das  nicht  der  Fall  ist,  macht  sich  bemerkbar,  dafi  sich  die  De¬ 
finition  des  Crossover  Nodes  zwischen  CIP  und  Hawaii  unterscheiden:  Bei  CIP  ist  der  CR 
der  erste  gemeinsame  Knoten  der  Wege  vom  alten  und  neuen  CIP  Node  zum  Gateway. 
Im  Falle  von  Hawaii  jedoch  bestimmt  sich  der  CR  aus  dem  ersten  gemeinsamen  Knoten 
zwischen  dem  Weg  vom  alten  AP  zum  DRR  und  dem  kiirzesten  Weg  zwischen  den  beiden 
Accesspoints.  Das  Ergebnis  ist  im  Bild  4.11  dargestellt  und  zeigt  eine  schlechte  Route 
nach  funf  Handoffs  unter  der  Annahmne,  dafi  Uj  <  t0)i  +  t0j-  ist.  Erst  mit  der  nachsten 
„Path  Refresh  Message"  konnte  die  Route  korrigiert  werden,  da  der  jeweilige  WIPPOA 
die  „Path  Setup  Refresh  Messages"  auf  dem  kiirzesten  Weg  zum  DRR  sendet.  Falls  die 
eingezeichnete  Route  gegeniiber  dem  direkten  Weg  zwischen  den  Routern  R3  und  Rq 
(aus)suboptimal  ist,  gilt  tcR, 3  <  to,i  +  to, 2  +  to, 3-  Das  bedeutet  gleichzeitig,  dafi  zusatzlich 
zu  den  wahrend  des  Handoffs  auftretenden  Verzogerungen  und/oder  Paketverlusten  bei 
der  Routenkorrektur  nachtraglich  auch  die  Reihenfolge  der  Pakete  durcheinander  gerat. 

Webbasierte  Anwendungen  und  Filetransfer 

Mobilitat  im  Allgemeinen  hat  von  Natur  aus  einen  negativen  Effekt  auf  Webbrowsing. 
Bei  der  Nutzung  eines  Protokolls  wie  HTTP  1.0  wird  eine  kurzzeitige  TCP-Verbindung 
zwischen  dem  Webserver  und  dem  MN  erstellt.  Dabei  ist  die  Wahrscheinlichkeit,  dafi  ein 
Handoff  genau  in  diese  Verbindung  fallt,  relativ  gering  und  auch  von  minimaler  Aus- 
wirkung.  Ein  Nebeneffekt  von  Mobilitat  jedoch  ist  das  Tunneln  zwischen  HA  und  dem 
fremden  Netzwerk,  wie  es  in  Mobile  IP  definiert  ist.  Wenn  eine  Webseite  iibertragen  wird, 
benutzt  das  erste  TCP-Paket  normaleweise  die  gesamte  MTU.  Durch  IP-in-IP  Kapselung 
wird  die  zulassige  Grofie  des  MTU-Feldes  tiberschritten.  Wenn  das  Paket  nicht  fragmen- 
tiert  werden  darf,  fiihrt  dies  zu  einem  ICMP  Fehler  und  zusatzlicher  Verzogerung  bei  jeder 
vergleichbaren  TCP-Verbindung.  Das  passiert  nicht,  wenn  sich  der  MN  in  seinem  Heimat- 
netz  bewegt,  dessen  Protokoll  Hawaii  oder  CIP  ist,  weil  sie  im  Gegensatz  zu  Mobile  IP 
und  HMIP  ohne  Tunneln  auskommen. 
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Im  Folgenden  sollen  die  Auswirkungen  regelmassiger  Handoffs  auf  TCP-Verbindungen, 
z.B.  durch  Filetransfers  gepriift  werden.  Dabei  simulieren  wir  zwischen  0  und  30  Handoffs 
pro  Minute,  indem  der  MN  zwischen  AP3  und  AP4  wechselt.  Darauf  basierend  wird  ein 
lang  dauernder  Download  vom  CN  zum  MN  betrachtet.  Fur  bessere  Simulationsergebnisse 
gehen  wir  davon  aus,  daB  das  Internet  (Abb.  4.9)  kein  Flaschenhals  ist,  sondern  ebenfalls 
eine  schnelle  Netzwerkverbindung  darstellt.  Das  Ergebnis  des  Versuchs  (siehe  4.12)  zeigt 
hier  einen  Vorteil  von  Paketverlust-minimierenden  Ansatzen.  CIP  Semisoft  und  Hawaii 
MSF  liefern  vergleichsweise  gute  Ergebnisse,  weil  die  moglicherweise  falsche  Reihenfolge 
und  Verzogerung  der  Pakete  auf  hoheren  Schichten  problemlos  bearbeitet  wird.  CIP  Hard 
Handoff  und  Hawaii  UNF  hingegen  nehmen  Paketverluste  in  Kauf,  was  in  einem  Abfall 
des  Durchsatzes  von  fast  25%  resultiert,  wenn  der  AP  alle  2  Sekunden  gewechselt  wird. 


Abbildung  4.12:  TCP  Durchsatz  auf  Anwendungsschicht,  aus  [8] 


4.6  Fazit 


Diese  Arbeit  soil  und  kann  keinen  bewertenden  Vergleich  zwischen  den  verschiedenen  Pro- 
tokollen  geben.  Insbesondere  im  vorigen  Kapitel  wurde  herausgestellt,  daB  sich  die  Pro- 
tokolle  und  ihre  einzelnen  Schemata  sehr  unterschiedlich  verhalten.  Das  grofite  Problem 
liegt  im  Einzelfall  darin,  den  Bedarf  an  verlust-  oder  verzogerungsfreien  Verbindungen  zu 
bewerten  und  gegeneinander  abzugrenzen.  In  der  heutigen  Situation  werden  IP-basierte 
Netzwerke  fur  eine  Vielzahl  von  Kommunikationssystemen  genutzt,  mit  ganz  unterschied- 
lichen  Anspriichen.  Dabei  seinen  hier  nur  nochmal  VoIP-Verbindungen  erwahnt,  die  ge- 
ringe  Paketverluste  zwar  verschmerzen,  aber  Verzogerungen  kaum  verkraften  konnen,  weil 
sie  dann  fur  kommerzielle  Anwendungen  nicht  konkurrenzfahig  sind,  wenn  sie  auch  noch 
so  giinstig  sein  mogen.  Der  mobile  Internetnutzer  hat  diese  Anspruche  nicht.  Gleichzeitig 
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hat  es  herausgestellt,  dafi  die  Protokolle  Hawaii  und  Cellular  IP  in  der  Simulation  gewisse 
Vorteile  gegeniiber  dem  Hierarchical  Mobile  IP  Protokoll  hatten.  Sie  haben  jedoch  den 
gravierenden  Nachteil,  dafi  sie  nicht  ohne  das  Ersetzen  aller  Router  einer  Domane,  also 
nur  mit  grofiem  Aufwand,  in  bestehende  Netze  integriert  werden  konnen,  wahrend  HMIP 
mit  der  Verwendung  von  Tunneln  keine  solchen  Probleme  kennt.  Was  sehr  viel  einfacher 
zu  bewerten  ist,  sind  die  Ideen,  die  den  Strategien  und  deren  Umsetzung  zugrunde  liegen. 
Das  sind  insbesondere  bei  den  „Konzeptstudien“  Fast  und  Proactive  Handoff  Uberlegun- 
gen,  die  Grenzen  zwischen  den  OSI-Schichten  2  und  3  zu  lockern.  Es  wurde  zweifellos 
herausgestellt,  dafi  diese  Ansatze  durchaus  grofie  Effekte  in  der  Optimierung  von  Han- 
doffverzogerungen  haben.  Das  Aufbrechen  des  ISO/OSI-Schichtenmodells  wird  derzeit 
an  vielen  Anwendungsgebieten  der  Kommunikation  diskutiert,  weil  es  durch  seine  strik- 
te  Trennung  der  Schichten  zahlreiche  Optimierungsmoglichkeiten  in  der  Kommunikation 
verhindert,  gleichzeitig  aber  auch  durch  jahrelangen  Bestand  seine  Existenzberechtigung 
hat.  Ein  Ansatz,  der  in  diesem  Zusammenhang  geaufiert  wurde,  ist  die  Definition  einer 
„Open  Radio  API“,  um  das  heterogene  Feld  bestehender  und  zukiinftiger  Kommunika- 
tionsmedien  zu  vereinheitlichen.  Dieser  Ansatz  wird  vermutlich  schwierig  zu  realisieren 
sein. 

Ein  weiterer,  bereits  mit  der  mobilen  Telekommunikation  eingefiihrter  Begriff  ist  Paging. 
Durch  die  Einfuhrung  eines  passiven  Zustands  kann  die  Frequenz  der  Location  Upda¬ 
tes  reduziert  werden.  So  kann  Energie  gespart  werden,  indem  nur  noch  der  L2-Stack 
regelmafiig  auf  wichtige  Pakete  untersucht  wird  und  nur  im  Bedarfsfall  gesendet  werden 
mufi.  Gleichzeitig  wird  damit  der  Kommunikationsaufwand  im  Netz  kaum  sinken,  da  im 
Durchschnitt  die  eingesparte  Kommunikation  innerhalb  des  Netzes  durch  Broadcasting 
wahrend  des  Suchens  eines  MN  ausgeglichen  wird.  Je  nach  Anwendungsgebiet  ist  dieser 
Aufwand  womoglich  unnotig  hoch.  Bei  einem  Notebook  beispielsweise  verbraucht  regelma- 
fiige  Kommunikation  nur  einen  Bruchteil  der  zur  Verfiigung  stehenden  Energie  gegeniiber 
Komponenten  wie  Festplatte,  Display  und  dem  Prozessor  selbst.  Ist  das  Gerat  jedoch  auf 
Standby,  sind  in  Zukunft  durchaus  Modelle  denkbar,  in  denen  der  MN  seine  Position  ak- 
tualisieren  sollte,  um  Dienste  wie  WakeOnLAN  fur  IP-basierte  Kommunikation  nutzen  zu 
konnen.  Dabei  wurde  stetige  Kommunikation  einen  sehr  viel  hoheren  Anteil  am  Energie- 
verbrauch  des  MNs  -  ahnlich  zu  Mobiltelefonen  -  darstellen,  und  Paging  eine  zunehmend 
wichtige  Rolle  spielen. 

Durch  die  Uberlegungen  zu  Mobilitat  in  IP-basierten  Netzen  ist  man  zwangslaufig  zu 
der  Einfuhrung  sogenannter  „A11-IP“  Netze  gekommen.  Diese  haben  zur  Folge,  dafi  die 
bekannten  Routingkonzepte  durch  neue,  in  jedem  Fall  kompliziertere  Strategien  ersetzt 
oder  erweitert  werden  miissen,  wie  es  in  den  einzelnen  Protokollen  beschrieben  wurde. 
Die  sich  daraus  ergebenden  Routing  Tabellen  miissen  riesige  Datenmengen  effizient  ver- 
arbeiten  und  insbesondere  aktualisieren  konnen.  Beispielweise  miissen  die  Gateways  der 
jeweiligen  Netze  stets  Eintrage  fur  jeden  einzelnen  MN  in  der  Hierarchie  verwalten.  Ob 
sich  diese  Ansatze  auch  in  grofie  Bereiche  der  heutigen  Netztopologie  integrieren  lassen, 
wird  abzuwarten  sein. 

Letztendlich  kann  man  jedoch  feststellen,  dafi  unter  dem  breiten  bestehender  Konzept- 
studien  und  Protokolle  zahlreiche  Ansatze  gefunden  wurden,  um  den  Problemen  im  Zu¬ 
sammenhang  mit  Mobilitat  zu  begegnen.  Eine  Gewichtung  der  Ergebnisse  und  absolute 
Bewertung  der  Protokollfahigkeiten  ware  die  Aufgabe  einer  weiteren  Arbeit,  die  einer 
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Ausrichtung  auf  ein  detailliert  vorgegebenes  Anwendungsgebiet  bedarf. 


Abkurzungsverzeichnis 

CIP  Das  Cellular  IP  Protokoll 

CIPR  Cellular  IP  Router 

CN  Correspondent  Node 

COA  Care  Of  Address 

CR  Crossover  Node 

FA  Foreign  Agent  (Mobile  IP,  HMIP) 

FN  Foreign  Network 

GFA  Gateway  Foreign  Agent  (HMIP) 

HA  Home  Agent  (Mobile  IP) 

HMIP  Hierarchical  Mobile  IP 
IMN  Idle  Mobile  Node  (Paging) 

MN  Mobile  Node 

MRP  Mobile  Routing  Point 

PA  Paging  Area 

PFA  Paging  Foreign  Agent 

SHRT  Strong  Handoff  Radio  Trigger 

WIPPOA  Wireless  IP  Point  Of  Attachment 
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Kapitel  5 

Quality  of  Service  in  Wireless  Local 
Area  Networks 

Andreas  Fischer 


Kabellose  Netzwerke  sind  in  verschiedenen  Varianten  verfugbar.  Nun  ist  es  fur  die  Pla - 
nung  und  den  Vergleich  von  solchen  Netzen  notwendig,  bestimmte  Kriterien  fesizulegen. 
Diese  werden  im  allgemeinen  mit  Quality  of  Service  zusammengefasst.  Aufgrund  der  be- 
sonderen  Eigenschaften  sind  in  der  drahtlosen  Umgebung  die  Mechanismen  auf  kabelge- 
bundenen  Netzen  nur  eingeschrankt  anwendbar.  Die  grundsatzlichen  Eigenschaften,  mit 
denen  die  Netze  beschrieben  werden,  sind  weitgehend  zu  denen  im  Kabelnetz  vergleichbar. 
Die  Mechanismen,  die  in  kabellosen  Netzen  zur  Anwendung  kommen,  werden  in  diesem 
Abschnitt  naher  betrachtet.  Dabei  ist  die  Arbeit  in  zwei  Bereiche  unterteilt:  im  ersten  Teil 
wird  beschrieben,  wie  eine  Bewertung  von  existenten  Netzen,  egal  welcher  Art,  moglich 
ist.  Der  Zweite  Absachnitt  beschaftigt  sich  dann  mit  den  Umsetzungen  von  Eigenschaften 
beziiglich  Quality  of  Service  in  vorgegebenen  Standards  wie  802.11. 
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5.1  Einleitung 


In  diesem  Seminar  wird  die  Umsetzung  von  Quality  of  Service  (im  Folgenden  QoS)in 
einer  Wireless  Local  Area  Network  Umgebung  betrachtet.  Dazu  werden  zwei  grundsatz- 
lich  verschieden  Ansatze  verfolgt.  Im  ersten  Teil  der  Arbeit  wird  die  Unterstiitzung  von 
QoS  innerhalb  der  standartisierten  Netze  nach  IEEE  802.11  betrachtet.  Hierbei  wird  der 
Vergleich  zu  anderen  Netzen  gezogen.  Der  Zweite  Teil  der  Arbeit  beschaftigt  sich  dann 
mit  der  Betrachtung  von  QoS  in  einem  vorgegebenen  Netz.  Dazu  wird  der  Ansatz  des 
Realtime  Traffic  Flow  Measurement  naher  verfolgt.  Dieser  beschreibt  eine  Betrachtung 
des  Datenverkehrs  unabhangig  von  der  Schicht  aus  dem  ISO/OSI-Referenzmodell. 


5.1.1  Einordnung  und  Bedeutung  von  Quality  of  Service 

Der  Begriff  “Quality  of  Service11,  deutsch  meist  “Dienstgiite11,  wird  in  der  Liter atur  teilwei- 
se  widerspriichlich  interpretiert.  Es  seien  hier  drei  gangige  Definitionen  beschrieben:  QoS 
definiert  als  die  Zusammenfassung  verschiedener  Kriterien,  die  die  Giite  eines  Netzwerk- 
Dienstes  beziiglich  Zeit  und  Zuverlassigkeit  betrachten,  Garantiewerte  der  Leistungsfahig- 
keit  eines  Datennetzes  beziiglich  Zeit  und  Zuverlassigkeit  oder  auch:  Anwendungen  eine 
bestimmte  Giite  des  Netzes  bezogen  auf  Zeit  und  Zuverlassigkeit  garantieren  zu  konnen. 

Im  weiteren  Verlauf  dieser  Arbeit  wahlen  wir  eine  etwas  weiter  gefasste  Definition  des 
Begriffes:  QoS  beschreibt  Anforderungen  an  ein  Kommunikationssystem  aus  einer  be- 
stimmten  Sicht.  Damit  schliefien  wir  auch  andere  Aspekte  als  Zuverlassigkeit  und  Zeit 
ein.  Dies  konnte  etwa  Bandbreite  oder  Sicherheit  sein.  Mit  der  Sicht  sei  beschrieben,  das 
die  Anforderungen  an  ein  Kommunikationsnetzwerk  je  nach  Betrachtungsweise  sehr  un- 
terschiedlich  sein  konnen.  Darauf  werde  ich  mit  Beispielen  im  folgenden  Gliederungspunkt 
weiter  eingehen. 

5.1.2  Betrachtung  anhand  von  verschiedenen  Metriken 

Definieren  wir  jetzt  also  gemafi  unserer  Definition  verschiedene  Metriken  der  Anforde¬ 
rungen.  Angemerkt  sei,  dass  hier  nur  ein  exemplarischer  Ausschnitt  dargestellt  werden 
kann. 

Die  Sicht  wird  hier  in  drei  verschiedene  Klassen  geteilt:  den  Provider,  den  Dienstanbieter 
und  den  Verbraucher.  Dabei  wir  der  Netzbetreiber  als  Provider  gesehen.  Fur  ihn  sind  Ziele 
wie  hohe  Auslastung  des  Netzes  und  geringe  Betriebskosten  interessant.  Als  Dienstanbieter 
ist  ein  moglicher  Verkaufer  gedacht,  dem  der  Provider  eine  bestimmte  Funktionalitat 
bereitstellt,  fiber  die  der  Kundenkontakt  und  die  Ubertragung  der  Leistung  erfolgt.  Ffir 
diesen  Teilnehmer  an  der  Kommunikation  sind  mogliche  Garantien  beziiglich  Sicherheit, 
Vertraulichkeit,  Integritat  der  Daten,  Zeit  besonders  wichtig,  um  seine  Dienstleistung 
anzubieten. 

Beschreiben  wir  zuerst  die  Kapazitat  von  Netzwerken.  Dies  ist,  eine  Metrik,  die  besonders 
ffir  die  Entwicklung  und  ffir  den  Betrieb  von  Netzwerken  interessant  ist.  Dazu  kann  man 
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etwa  die  Kapazitat  von  Netzwerken  beziiglich  der  moglichen  Anzahl  der  Knoten  oder  der 
Endsysteme  betrachten.  Dazu  besteht  oft  eine  Abhangigkeit  von  den  Datenmengen,  die 
iiber  das  Netz  transportiert  werden.  Somit  kann  unter  dem  Begriff  Kapazitat  auch  die 
Bandbreite  zu  verstehen  sein,  die  das  entsprechende  Netz  besitzt.  Weiterhin  kann  fiir  den 
Netzbetreiber  die  mogliche  Ausdehnung  des  Netzes  einen  Einfluss  auf  die  Anwendungs- 
moglichkeiten  haben. 

Eine  Metrik,  insbesondere  in  Bezug  auf  Sicherheit,  ist  die  Fehlerrate.  Auch  diese  ist  fiir 
den  Provider  von  Bedeutung.  Die  Fehlerrate  kann  Einfluss  auf  die  Gesamtdatenmenge 
haben.  So  wird  unter  Umstanden  eine  Neuiibertragung  von  fehlerhaften  Paketen  angeregt 
werden.  Dies  ist  auch  fiir  einen  Dienstanbieter  ein  entscheidendes  Merkmal,  um  zwischen 
verschiedenen  Providern  zu  wahlen.  Weiterhin  konnen  Applikationen  den  Fehlerraten  an- 
gepasst  werden,  um  auf  hoherer  Ebene  eine  fehlerlose  Ubertragung  zu  ermoglichen.  So  ist 
die  Fehlerrate  also  fiir  Dienstanbieter  und  Provider  ein  wichtiges  Merkmal  zur  Bewertung 
von  Kommunikationsnetzwerken. 

Eine  weitere  Metrik,  die  besonders  fiir  iibergeordnete  Schichten  nach  dem  ISO/OSI- 
Referenzmodell  von  Bedeutung  ist,  stellt  sich  in  Form  der  Varianz  der  Verzogerungszeiten 
(englisch:  Jitter)  dar.  Dieser  Wert  ist  insbesondere  fiir  Real-Time-Anwendungen  inter- 
essant.  Entsprechende  Garantien  sind,  wie  bereits  in  Teil  3  dieses  Seminars  beschrieben, 
besonders  in  drahtlosen  Umgebungen  nur  schwer  zu  realisieren. 

Dazu  kommen  einige  Metriken,  die  fiir  den  Provider  weniger  interessant  sind.  Dazu  ge- 
horen  etwa  Verzogerungs-  und  Antwortzeiten.  Das  heifit  aber  nicht,  dass  entsprechende 
Werte  fiir  den  Netzbetrieb  unwichtig  sind.  Kunde  und  Dienstanbieter  sind  an  einer  defi- 
nierten  Leistung  des  Netzes  in  Bezug  auf  diese  Metriken  interessiert.  So  macht  es  fiir  den 
Betreiber  einer  Internetseite  einen  erheblichen  Unterschied,  ob  http-Anfragen  in  kurzer 
Zeit  beantwortet  werden  konnen  oder  ob  sich  fiir  den  Kunden  eine  groBe  Verzogerung 
ergibt. 

Ein  erheblicher  Teil  der  Antwortzeit  fiir  den  Kunden  ergibt  sich  aus  der  Latenzzeit  der 
Ubertragung  im  Netz.  Daher  ist  es  moglich,  das  Servererweiterungen  nur  einen  geringen 
Einfluss  auf  die  Antwortzeit  hat.  Weitere  Moglichkeiten  fiir  die  Bewertung  von  Netzwerken 
sind  Aufbauzeit  und  Haltezeit  fiir  eine  Verbindung.  Auch  diese  Metriken  sind  fiir  Kunden 
und  Dienstanbieter  entscheidend,  um  auf  hoheren  Ebenen  damit  umzugehen. 


5.2  QoS  nach  IEEE  802.1  p 

Fiir  eine  Netzstruktur  nach  den  Spezifikationen  der  IEEE  hat  das  Gremium  einen  Stan¬ 
dard  fiir  QoS  in  IEEE  802.1  p  gesetzt.  Hier  werden  QoS  die  folgenden  Metriken  zugeordnet: 
Service  Availebility  beschreibt  die  Verfiigbarkeit  der  Verbindungsstruktur  fiir  ein  Endge- 
rat.  Dabei  wird  die  Rate  zwischen  Verfiigbarkeit  und  keiner  Verfiigbarkeit  gemessen.  Um 
die  Verfiigbarkeit  zu  erhohen,  soil  eine  automatische  Wiederherstellung  der  Konfiguration 
implementiert  werden. 

Weiterhin  wird  der  Paketverlust  als  Metrik  fiir  QoS  beschrieben.  Der  Verlust  von  Paketen 
auf  der  Schicht  2  ist  selten,  aber  da  eine  Ubertragung  nicht  garantiert  ist,  wird  dieser 
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Punkt  in  die  QoS-Betrachtungen  auf  der  Ebene  2  des  ISO/OSI-Referenzmodells  einbe- 
zogen.  Der  Verlust  von  Datenpaketen  kann  unter  anderem  an  der  begrenzten  Kapazitat 
der  Pufferspeicher  in  den  Netzkomponenten  liegen.  Weiterhin  kann  er  durch  eine  lange 
Laufzeit  bedingt  sein.  Wenn  die  Laufzeit  das  TTL-Feld  des  Frames  iibersteigt,  wird  dieser 
verworfen. 

In  der  Spezifikation  wird  auch  die  Reihenfolge  von  Datenpaketen  betrachtet.  Wird  diese 
also  im  Netz  verandert,  kann  es  zu  einer  Veranderung  der  Information  kommen.  Daher 
ist  die  Reihenfolge  auch  fur  QoS  interessant, 

Innerhalb  der  Schicht  2  wird  kein  Datenpaket  dupliziert,  da  die  Vorgaben  dieses  Standards 
sich  nicht  nur  auf  die  MAC-Ebene  beziehen,  ist  die  Vervielfaltigung  von  Frames  hier  mit 
aufgefiihrt,  wird  im  betrachteten  Zusammenhang  allerdings  nicht  weiter  ausgefuhrt. 

Wie  in  fast  alien  Definitionen  von  QoS  wird  auch  in  dieser  die  Verzogerungszeit  betrachtet. 
Damit  ist  in  diesem  Zusammenhang  die  Zeit  zwischen  der  Anfrage  und  der  erfolgreichen 
Ubertragung  der  entsprechenden  Antwort  zu  verstehen. 

Wie  bereits  beschrieben  haben  die  Datenpakete  eine  Lebenszeit.  Wird  diese  iiberschritten, 
wird  der  Frame  nicht  weiter  iibertragen.  Das  hat  einen  Einfluss  auf  verschieden  andere 
Metriken  von  QoS. 

Die  Frames  auf  Schicht  2  haben  eine  Obergrenze  bezuglich  ihrer  Grofie.  Damit  ergibt  sich 
ebenfalls  eine  maximale  Grofie  der  Daten,  die  innerhalb  eines  Paketes  iibertragen  werden 
konnen. 

Neben  diesen  Metriken  sind  in  den  Spezifikationen  eine  Benutzerpriorisierung  und  der 
Durchsatz  definiert.  Diese  sind  auf  den  Ebenen  1  und  2  jedoch  nicht  umgesetzt. 


5.3  Betrachtung  von  QoS  mittels  RTFM 

Die  Analyse  von  Netzen  unter  den  bisher  beschriebenen  Metriken  ist  sehr  komplex.  Im 
Folgenden  wird  eine  Moglichkeit  zur  Bewertung  von  Netzverhalten  beschrieben.  Hier  ist 
kein  Schwerpunkt  auf  die  Metriken  von  QoS  gesetzt,  aber  durch  den  freien  Ansatz  konnen 
insbesondere  solche  betrachtet  werden. 

Schauen  wir  also  auf  die  grundlegenden  Eigenschaften  von  Realtime  Traffic  Flow  Measu¬ 
rement.  Dieser  Standard  wurde  innerhalb  einer  Arbeitsgruppe  der  Internet  Engineering 
Task  Force  entwickelt.  Ziel  ist  ein  applikationsorientiertes  Interface  zur  Bewertung  von 
Datenstromen.  Dazu  muss  ein  Datenstrom  (im  Folgenden  Flow)  definiert  werden.  Im  Zu¬ 
sammenhang  der  IETF  wird  eine  relativ  freie  Definition  genutzt.  Ein  Flow  besteht  aus 
verschiedenen  Paketen,  die  logisch  zusammenhangen.  Wie  der  Zusammenhang  dabei  zu 
verstehen  ist,  wird  nicht  spezifiziert.  Denken  wir  an  die  QoS-Metriken,  sind  hier  etwa 
zeitliche  Zusammenhange  denkbar.  Weiterhin  konnen  im  allgemeinen  Umfeld  Quell-  und 
Zieladressen  betrachtet  werden.  Es  sind  aber  auch  ganz  andere  Zusammenhange,  wie  Gro¬ 
fie  oder  Prioritat  denkbar. 
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Abbildung  5.1:  Aufbau  von  RTFM 


Die  Architektur  von  RTFM  gliedert  sich  in  vier  Teile,  die  interagieren.  Die  Funktions- 
einheit,  die  den  eigentlichen  Datenverkehr  iiberwacht,  ist  der  Traffic  Meter.  Vom  Meter 
Reader  werden  die  gesammmelt  und  geordnet.  Die  strukturierten  Daten  des  Meter  Reader 
werden  zur  Analysis  Application  iibertragen  und  hier  ausgewertet.  Zur  Administration  des 
Ablaufes  ist  der  Manager  unabhangig  von  alien  anderen  Einheiten  installiert. 


5J3.I  Traffic  Meter 

Der  Traffic  Meter  ist  eine  Einheit,  die  Daten  zum  Betrieb  an  einem  bestimmten  Punkt 
innerhalb  des  Netzwerkes,  dem  Metering  Point,  sammelt.  Er  kann  in  verschiedenen  Formen 
ausgefiihrt  sein:  wird  der  Datenstrom  in  einem  Host  des  Netzwerkes  betrachtet,  kann  die 
Funktionalitat  in  einem  Programmteil  der  Software  abgebildet  sein.  Hier  wird  dann  der 
Header  der  Pakete  betrachtet  und  nach  gewissen  Eigenschaften  ausgewertet.  Wird  ein 
System  mit  verschiedenen  Netzzugangen  bewertet,  so  wird  eine  Struktur  verwendet,  die  die 
Pakete  an  alien  Zugangen  analysieren  kann.  Damit  kann  jeder  Zusammenhang  zwischen 
verschiedenen  Zugangspunkten  betrachtet  werden.  Ein  Spezialfall  dieses  Szenarios  wird 
in  Knoten  verwendet,  die  Pakete  weiterleiten;  so  etwa  Switch  oder  Router. 

Der  Traffic  Meter  benotigt  zur  Auswertung  des  Datenverkehrs  im  Netzwerk  ein  bestimm- 
tes  Wissen.  So  miissen  ihm  sowohl  die  Flow-Spezifikation  als  auch  die  Flow-Attribute 
bekannt  sein.  Dazu  kommt  ein  bestimmtes  Verhalten  bei  der  Aufzeichnung  der  Daten. 
Dabei  konnten  etwa  nur  ausgewahlte  Pakete  betrachtet  werden.  So  ist  es  moglich,  jedes 
n-te  Paket  oder  Pakete  ab  einer  bestimmten  GroBe  in  die  Bewertung  einzubeziehen.  Diese 
Anforderungen  an  den  Traffic  Meter  erfordern  einen  Speicher  sowie  Rechenkapazitat. 

Die  Arbeitsweise  eines  Traffic  Meters  stellt  sich  wie  folgt  dar.  Ein  Packet  Processor  emp- 
fangt  die  Pakete.  Dabei  betrachtet  er  den  Paketkopf  und  liest  den  Match  Key  aus.  Durch 
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Abbildung  5.2:  Paketverarbeitung  nach  RTFM 


den  Match  Key  wird  ein  Paket  eindeutig  bestimmt.  Der  Match  Key  wir  dann  an  die  Packet 
Matching  Eingine  iibergeben.  Hier  liegen  die  einzelnen  Flow-Spezifikationen  vor.  Anhand 
des  Match  Key  und  der  Spezifikationen  wird  der  Flow  Key  bestimmt.  Dieser  ordnet  das 
Paket  einem  Flow  zu.  Die  gesammelten  Informationen  werden  jetzt  an  den  Meter  Reader 
iibertragen.  Unter  dem  Flow  Key  werden  die  entsprechenden  Paketinformationen  vom 
Packet  Processor  in  den  Flow-Table  geschrieben. 

Ein  Eintrag  in  den  Flow  Table  enthalt  midestens  folgende  Daten: 


•  Adressen  von  Absender  und  Addressat,  welche  schichtunabhangig  gestaltet  sind 

•  Zeitstempel  des  ersten  und  des  letzten  Paket vorkommens  des  Flow. 

•  Zahler  fiir  Hin-  und  Riickrichtung  des  zum  Flow  gehorigen  Verkehrs 

•  weitere  frei  definierbare  Attribute 

Die  einzelnen  Datenstrome  konnen  die  konnen  nach  folgenden  Zustanden  unterschieden 
werden: 


•  Inaktiv,  wenn  der  Flow  Record  nicht  vom  Traffic  Meter  genutz  wird 

•  Current,  wenn  der  entsprechende  Flow  vom  Meter  genutzt  wird,  um  Pakete  zu  ana- 
lysieren 

•  Idle,  wenn  der  Record  zwar  vom  Meter  genutzt  wird,  aber  fiir  eine  spezifizierte  Zeit 
keine  Pakete  zum  entsprechenden  Flow  zugeordnet  wurden 

end  itemize  Dazu  konnen  hier  weitere  Funktionalitaten  existent  sein. 
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5.3.2  Meter  Reader 

Die  so  gesammelten  Daten  werden  dann  iiber  ein  festes  Interface  zu  vom  Manager  de- 
finierten  Zeiten  an  den  Meter  Reader  iibertragen.  Hier  erfolgt  die  Zusammenstellung 
in  zu  einem  Flow  Data  File.  Dazu  werden  im  Standard  keine  weiteren  Ausfiihrungen 
gemacht. 


5.3.3  Analysis  Application 

Die  vom  Meter  Reader  gesammelten  Daten  werden  an  die  Analysis  Application 
iibergeben.  Dazu  macht  der  Standard  keine  weiteren  Ausfiihrungen.  Es  ist  nach 
den  Vorgaben  auch  moglich,  mit  der  Applikation  in  das  Netzwerk  einzugreifen.  So 
ware  ein  Eingriff  in  die  Netzwerktopologie  denkbar.  Damit  wiirde  eine  dynamische 
Netzwerkstruktur  entstehen.  Dies  konnte  insbesondere  fur  Multiprozessorsysteme 
interessant  sein. 

5.3.4  Manager 

Dazu  kommt  der  Manager.  Seine  Funktionalitat  besteht  in  der  Konfiguration  von 
Traffic  Meter  und  Meter  Reader.  Dies  geschieht  mittels  folgender  Funktionen: 

-  Kontrollfunktionen  zwischen  Manager  und  Meter 

*  Download  Rule  Set,  um  Rule  Sets  beliebiger  Art  auf  den  Meter  zu  iiber- 
tragen 

*  Specify  Meter  Task,  um  genau  einen  Rule  Set  auszuwahlen  und  zur  An- 
wendung  zu  bringen 

*  Set  high  water  mark,  um  den  Flow  Table  in  der  Grofie  zu  begrenzen 

*  Set  flow  termination  parameters,  um  das  Ende  des  Flows  zu  spezifizieren 

—  Kontrollfunktionen  zwischen  Manager  und  Meter  Reader 

*  Identification  between  Manager  and  Meter  reader 

*  Reporting  Interval  Control,  um  den  Abstand  zwischen  zwei  Berichten  vom 
Meter  zum  Meter  Reader  zu  bestimmen 

*  Granularity  Control,  um  die  Granularitat  der  aufzuzeichnenden  Daten  zu 
bestimmen 

*  Flow  Lifetime  Control,  um  zu  bestimmen,  wie  lange  die  Daten  zu  einem 
inaktiven  Flow  nachgehalten  werden 

Metriken,  die  dem  Flow  nach  RTFM  zugeordnet  werden  miissen,  sind  Lebenszeit, 
Zahler  und  Zeitstempel.  Dabei  sind  die  Zahler  als  Rolling  Counter  auszulegen.  Einfa- 
che  Zahler  waren  mit  der  Instanziierung  des  Flow  zu  beginnen.  Dann  wird  der  Zahler 
einfach  erhoht,  solange  der  Flow  existent  ist.  Der  Rolling  Counter  wird,  sobald  die 
Informationen  vom  Meter  Reader  an  die  Analysis  Application  weitergegeben  wird, 
zuriickgesetzt.  Durch  dieses  System  wird  das  Verfahren  weniger  fehleranfallig.  Soil- 
ten  bestimmte  Einheiten  der  gesammelten  Informationen  verloren  gehen,  wird  die 
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Analyse  von  dem  Teil  einfach  ausgeblendet,  die  Analyse  des  gesamten  Flow  bleibt 
davon  nahezu  unbeeintrachtigt.  Neben  den  vorgegebenen  Parametern  kann  man  frei 
weitere  definiefen.  So  ist  es  moglich,  etwa  die  Stationen  von  Paketen  aufzuzeichnen. 
Damit  ist  leicht  ersichtlich,  dass  es  mit  dem  RTFM-Ansatz  die  Moglichkeit  bietet, 
den  Datenverkehr  in  bestimmten  Netzen  anhand  von  QoS-Metriken  zu  analysieren. 
Damit  ist  ein  Hilfsmittel  zu  Bewertung  von  QoS  gegeben. 

5.4  Unterstutzung  von  QoS  in  verschiedenen  Stan¬ 
dards 

5.4.1  Wireless  Local  Area  Networks  nach  IEEE  802.11 

Betrachten  wir  jetzt  die  Umgebung  nach  der  Spezifikation  802.11  der  IEEE.  Dieser 
Standard  spezifiziert  eine  Wireless  Local  Area  Network  Umgebung.  Entsprechende 
Gerate  sind  in  vielfaltigen  Varianten  am  Markt.  Fast  alle  Gerate  aus  dem  Bereich 
der  Wireless  Networks  entsprechen  mindestens  einem  Standard  der  802.11  Gruppe. 
Die  IEEE  hat  in  verschiedenen  Varianten  der  Entwicklung  der  Funkubertragung 
Rechnung  getragen.  So  sind  verschiedene  Netzwerkspezifikationen  entstanden,  die 
im  Wesentlichen  unterschiedliche  Ubertragungsraten  ermoglichen.  Der  derzeit  wohl 
gebrauchlichste  Standard  ist  IEEE  802.11  b  mit  einer  maximalen  Ubertragungsra- 
te  von  11  Mbit/s.  Andere  Standards,  wie  etwa  802.11  a  und  802.11  g  haben  eine 
maximale  Ubertragungsrate  von  54  Mbit/s.  Sie  sind  teilweise  kompatibel  zu  802.11 
b  mit  entsprechend  geringeren  Datenraten.  Die  Reichweite  der  Gerate  im  Standard 
802.11  b  betragt  je  nach  Umgebung  etwa  25  bis  50  Meter. 


Abbildung  5.3:  Einordnung  von  WLAN  nach  802.11 


Die  Spezifikationen  aller  Standards  802.11  erstrecken  sich  iiber  die  Schichten  eins 
und  zwei  des  ISO/OSI-Referenzmodells.  In  der  Gesamtarchitektur,  die  durch  die 
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IEEE  beschrieben  ist,  bietet  802.11  eine  Schnittstelle  nach  oben  an.  Parallel  zu 
der  WLAN-Umgebung  konnen  auch  Netzwerke  wie  etwa  Ethernet  oder  Token  Ring 
eingesetz  werden.  Dur  die  weitgehende  Transparenz  der  Schnittstelle  ist  hier  die 
Moglichkeit  gegeben,  diese  Netze  in  einer  gemeinsamen  Umgebung  anzuwenden,  so 
wie  es  im  Internet  realisiert  ist.  Auf  dieser  Schnittstelle  arbeiten  dann  verschiedene 
Protokolle  des  Bereiches  Bridging  und  Logical  Link  Control. 
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Abbildung  5.4:  Gliederung  der  Bitiibertragungsschicht  nach  802.11 

Innerhalb  der  Standardisierung  802.11  konnen  auf  der  Schicht  eins  vier  verschieden 
Verfahren  genutzt  werden.  Alle  bieten  unter  unterschiedlichen  Paketrahmen  die  glei- 
che  Funktionalitat  an,  so  dass  dann  auf  der  Schicht  zwei  nur  ein  einziges  Paketformat 
existiert. 

Im  Folgenden  wird  beschrieben,  welche  einzelnen  Felder  innerhalb  der  Pakete  der 
Ubertragung  zur  Informationsgewinnung  beziiglich  QoS  genutzt  werden  konnen.  Be- 
trachten  wir  zuerst  den  MAC-Frame  auf  Schicht  zwei. 

Der  Paketkopf  der  MAC-Datenpakete  hat  eine  feste  Lange  von  240  Bit.  Er  besteht 
aus  einem  16  Bit  langem  Feld  zur  Paketkontrolle.  Dazu  kommen  jeweils  16  Bit 
Duration/ID  und  Sequenzkontrolle.  Mit  dem  Feld  Duration  wird  die  Dauer  der  Pa- 
ketiibertragung  iibertragen.  Dies  ist  notwendig,  da  die  Grofie  des  zu  iibertragenden 
Datums  nicht  festgelegt  ist.  Mit  den  16  Bit  Sequenzkontrolle  ist  es  moglich,  65536 
Datenpakete  in  einer  Sequenz  zu  iibertragen.  Damit  ergeben  sich  maximal  etwas 
mehr  als  1,5  GB  in  einer  Sequenz. 
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Abbildung  5.5:  M AC-Frame  nach  IEEE  802.11 


Type  und  Subtype-Feld  des  Paketkontrollkopfes  spezifizieren  die  Art  des  MAC- 
Frames.  Es  gibt  Management-Frames,  die  zum  Beispiel  bei  der  Assoziierung  von 
Stationen  verwendet  werden,  Control-Frames  wie  RTS/CTS  und  Data-Frames. 

Die  anderen  Flags  im  zwei  Byte  breiten  Frame  Control-Feld  geben  an,  ob  es  sich 
nm  einen  Frame  zum  oder  vom  Distribution  System  (DS)  handelt,  ob  noch  weite- 
re  Fragmente  folgen,  da  die  MSDU  geteilt  wurde,  ob  es  sich  um  eine  wiederholte 
Verschickung  des  Frames  handelt,  ob  die  sendende  Station  sich  im  Power-Saving- 
Modus  befindet,  ob  sie  weitere  Daten  versenden  will  und  ob  die  Daten  mittels  WEP 
verschlfisselt  sind  und  Fragmente  in  der  richtigen  Reihenfolge  versandt  werden. 

Bei  Control  Frames  sind  alle  1  Bit-Flags  mit  Ausnahme  des  Power  Management- 
Flags  auf  Null  gesetzt.  Der  IEEE  802.11-MAC  unterscheidet  fiinf  verschiedene  MAC- 
Adressen,  die  Basic  Service  Set  Identification  (BSSID),  Destination  Address  (DA), 
Source  Address  (SA),  Receiver  Address  (RA)  und  Transmitter  Address  (TA).  Die 
BSSID  ist  in  der  Regel  die  MAC-Adresse  des  Access  Points.  Der  AP  ist  auch  die 
Station,  an  die  Frames  mit  gesetztem  To  DS-Flag  gesendet  werden  beziehungsweise 
die  Station,  die  Frames  mit  gesetztem  From  DS-Flag  versendet.  Die  Anzahl  der 
verwendeten  Adrefifelder  sowie  deren  Inhalt  (BSSID,  DA,  SA,  RA  oder  TA),  werden 
von  den  Flags  To  DS  und  From  DS  festgelegt.  Sind  beide  Flags  1,  werden  nur  die 
Adressen  1  bis  4  belegt.  In  alien  anderen  Fallen  entfallt  Adresse  4,  so  dass  der 
Paketkopf  nur  192  Bit  lang  ist.  Sind  beide  Flags  0,  so  ist  Adresse  1  die  DA,  Adresse 
2  SA  und  Adresse  3  BSSID.  Ist  To  DS  0  und  From  DS  1,  so  beschreibt  Adresse  1  die 
DA,  Adresse  2  BSSID  und  Adresse  3  die  SA.  Bei  der  Belegung  To  DS  1  und  From  DS 
0  steht  die  BSSID  in  Adresse  1,  die  SA  in  Adresse  2  und  die  DA  in  Adresse  3.  Sind 
beide  Flags  1,  werden  wie  beschrieben  alle  vier  Adressen  besetzt.  Dazu  ist  Adresse 
1  mit  RA  belegt,  in  Adresse  2  findet  sich  die  TA.  Adresse  3  und  4  beschreiben  DA 
und  SA. 

Es  werden  neben  Unicast-Adressen  auch  Multicast-  und  Broadcast-Adressen  ver¬ 
wendet.  Die  Broadcast- Adresse  lautet  111.... 111.  Wahrend  Frames  an  eine  Unicast- 
Adresse  in  der  Regel  vom  Empfanger  durch  Versenden  eines  ACK  bestatigt  werden, 
geschieht  dies  bei  Frames  an  eine  Multicast-  oder  Broadcast- Adresse  nicht,  da  es 
durch  das  zeitgleiche  Versenden  der  ACK-Frames  von  alien  Empfangsstationen  zu 
einer  Kollision  kommen  wurde. 

Das  FCS-Feld  enthalt  einen  32  Bit-CRC-Code  fiber  den  gesamten  Frame  inklusi- 
ve  Frame  Body.  Ist  ein  empfangener  Frame  fehlerhaft,  so  wird  es  an  diesem  Feld 
erkannt.  Fehlerhafte  Frames  werden  nicht  bestatigt. 
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Wesentlich  fiir  QoS  sind  die  folgenden  Informationen  des  Paketkopfes:  Type  und 
Subtype,  More  Fragmentation,  Retry,  More  Data,  WEP  und  Order  aus  dem  Bereich 
Frame  Control  sowie  Duration/ID  und  Sequence  Control.  Mit  den  Feldern  Type 
und  Subtype  werden.  wie  bereits  beschrieben,  verschiedene  Framearten  bestimmt. 
Diese  konnen  im  Netz  unterschiedlich  behandelt  werden.  So  wird  eine  Bestatigung 
immer  nur  mit  einem  Short  Interframe  Space  versandt.  Damit  ergibt  sich  eine  hohere 
Prioritat.  Das  Feld  Retry  beschreibt  eine  erneute  Ubertragung.  an  diesem  Feld  kann 
auch,  der  Empfanger  erkennen,  dass  ein  vorheriger  Ubertragungsversuch  fehlerhaft 
war. 

Mit  dem  Feld  More  Data  kann  der  Adressat  des  Paketes  verifizieren,  ob  dieses  Paket 
mit  anderen  in  Zusammenhang  steht  oder  der  Inhalt  isoliert  betrachtet  werden  kann. 
Das  Feld  WEP  signalisiert,  dass  das  Nutzdatum  mit  Wired  Equivalent  Privacy,  dem 
Sicherheitsprotokoll  von  802.11,  verschliisselt  ist. 

Das  Order-Feld  wird  gesetzt,  wenn  die  Pakete  in  einer  bestimmten  Reihenfolge  ver¬ 
sandt  wurden  und  die  Nutzdaten  so  zu  interpretieren  sind.  Duration/ID  beschreibt 
die  Lange  der  Frameubertragung.  Damit  ist  es  moglich,  in  Netzkomponenten  be- 
stimmte  Schedulingalgorithmen  fiir  die  Bearbeitung  der  Pakete  zu  implementieren. 
Damit  kann  man  eine  Priorisierung  von  Paketen  anhand  deren  Lange  vornehmen. 
Mit  der  Sequenzkontrolle  ist  es  moglich,  bestimmte  Frames  in  einer  Sequenz  zu 
iibertragen,  so  dass  sie  am  Empfanger  in  die  vorgegebene  Reihenfolge  zu  bringen 
sind. 

Kommen  wir  jetzt  zu  den  Datenpaketen  auf  Schicht  eins.  Hier  sind  vier  verschiedene 
Verfahren  zur  Dateniibertragung  spezifiziert:  Frequency  Hopping  Spread  Spectrum 
(FHSS),  Direct  Sequence  Spread  Spectrum  (DSSS),  Orthogonal  Frequency  Devision 
Multiplexing  (OFDM)  und  High  Rate  Direct  Sequence  Sprad  Spectrum  (HR/DSSS) . 
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Abbildung  5.6:  FHSS-Frame  nach  IEEE  802.11 


Der  FHSS-Frame  besteht  aus  den  Feldern  Synchronisation,  SFD,  PLW,  PSF  und  HEC. 
Der  Paketkopf  hat  eine  Gesamtlange  von  128  Bit.  Die  Felder  Synchronisation  und  Start 
Frame  Delimiter  bestimmen  die  PLCP-Praambel.  Der  PLCP-Paketkopf  enthalt  die  Fel¬ 
der  Payload  Length  Word,  Payload  Signalling  Field  und  Header  Error  Check.  Fiir  QoS- 
Eigenschaften  kommt  hier  nur  die  Nutzung  des  Feldes  Payload  Signalling  Field  in  Frage, 
in  dem  die  Datenrate  der  Ubertragung  des  Nutzdatums  bestimmt  ist.  Hierbei  steht  0000 
fiir  1  Mbit/s,  die  maximale  Ubertragungsrate  betragt  8,5  Mbit/s  und  wird  mit  1111  ge- 
kennzeichnet. 
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Abbildung  5.7:  DSSS-Frame  nach  IEEE  802.11 
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Der  DSSS-Header  ist  grundsatzlich  192  Bit  lang,  die  sich  auf  die  Felder  Synchronisation, 
Start  Frame  Delimiter,  Signal,  Service,  Length  und  Header  Error  Check  verteilen.  Die 
Datenrate  der  Nutzdaten  wird  hier  im  Feld  Signal  iibertragen.  Dabei  sind  vier  verschieden 
Datenraten  vorgegeben,  die  sich  in  Hexadezimalzahlen  wie  folgt  wieder  finden:  OA  fur  1 
Mbit/s,  14  fiir  2  Mbit/s,  37  fur  5,5  Mbit/s  und  6E  fur  11  Mbit/s.  Die  anderen  Felder 
haben  fiir  QoS-Eigenschaften  keine  Bedeutung. 
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Abbildung  5.8:  OFDM-Frame  nach  IEEE  802.11 

Bei  der  OFDM-Ubertragung  ist  der  Paketkopf  nur  40  Bit  lang.  Hier  bestimmt  das  Feld 
Rate  die  Datenrate  des  Nutzdatums.  Dazu  steht  die  3  fiir  54  Mbit/s,  die  9  fiir  24  Mbit/s 
und  die  Zahl  F  fiir  9  Mbit/s.  In  den  anderen  Feldern  werden  Informationen  iibertragen, 
die  fiir  QoS  ohne  Bedeutung  sind. 
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Abbildung  5.9:  HR/DSSS-Frame  nach  IEEE  802.11 


Den  HR/DSSS-Frame  gibt  es  mit  zwei  verschiedenen  Paketkopfen,  die  sich  nur  in  der 
Lange  der  Synchronisation  unterscheiden.  Mit  einer  kurzen  Synchronisation  ergibt  sich 
eine  Gesamtlange  des  Header  von  120  Bit,  mit  der  langen  Synchronisation  192  Bit.  Auch  in 
diesem  Paket  wird  im  Feld  Signal  die  Datenrate  iibertragen.  Die  anderen  Felder  enthalten 
keine  Informationen,  die  in  Bezug  auf  QoS  von  Bedeutung  sind. 


5.4.2  Virtual  Bridged  Local  Area  Networks 
nach  IEEE  802.1  Q 

Das  VLAN  nach  dem  Standard  der  IEEE  bezieht  sich  auf  die  Ebene  zwei  des  ISO/OSI- 
Referenzmodells.  Grundsatzlich  werden  hier  drei  verschiedene  Paktarten  unterschieden. 
Untagged  Frames  werden  nicht  direkt  einer  Gruppe  von  Teilnehmern  zugewiesen.  Die 
Zuordnung  kann  jedoch  nach  Kriterien  wie  etwa  der  Absenderadresse  oder  der  Zieladresse 
erfolgen.  Die  zweite  Klasse  an  Paketen  sind  die  Priority  Tagged  Frames.  Diese  besitzen 
zwar  eine  Prioritat,  werden  damit  aber  keinem  VLAN  zugeordnet.  Dies  geschieht,  wie 
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auch  bei  den  Untagged  Frames,  nach  anderen  Parametern,  wie  etwa  Adressen.  Die  dritte 
Gruppe  der  Pakete  sind  die  VLAN-tagged  Frames.  Diese  werden  nach  dem  entsprechenden 
Tag  zu  verschiedenen  VLAN-Umgebungen  zugeordnet.  Hier  werden  im  Netz  feste  VLAN 
implementiert,  die  nur  iiber  die  Administration  geandert  werden.  Dazu  gehort  dann  auch 
die  entsprechende  Einstellung  der  Netzwerkelemente,  wie  zum  Beispiel  der  Switches. 

Damit  die  Pakete  im  Netz  entsprechen  behandelt  werden,  ergibt  sich  die  Notwendigkeit  fur 
bestimmte  Funktionalitaten  der  Elemente.  Da  der  Standard  auf  Schicht  zwei  aufsetzt,  sind 
hier  die  Vorgaben  fur  Bridges  zu  definieren.  Es  werden  verschieden  Funktionen  beschrie- 
ben,  die  in  einer  Bridge  realisiert  sein  miissen,  dass  der  Einsatz  in  einer  VLAN-Umgebung 
sinnvoll  ist. 

Zu  implementieren  sind  die  folgenden  Funktionen:  Paketannahme,  das  Verwerfen  von  feh- 
lerhaften  Paketen  nach  dem  Standard  ISO/IEC  15802-3,  das  Verwerfen  von  Paketen,  die 
keine  Nutzdaten  enthalten,  Wiederherstellung  der  Benutzerprioritat  im  Bedarfsfall,  Ver¬ 
werfen  von  Paketen  nach  Vorgaben  der  Filterinformationen,  Verwerfen  von  Paketen  mit 
zu  grofiem  Nutzdatum,  Paketweiterleitung  an  einen  bestimmten  Port,  Auswahl  nach  Ver- 
kehrsklassen  nach  den  Filterinformationen,  Pufferung  der  Pakete  nach  Verkehrsklassen, 
Verwerfen  von  Paketen,  um  die  maximale  Verzogerungszeit  der  Bridge  zu  gewahrleisten, 
Auswahl  aus  den  gepufferten  Datenpaketen  zur  Weiterleitung,  Auswahl  einer  minimalen 
Benutzerprioritat,  die  bedient  wird,  Bearbeitung  der  Nutzdaten  und  Neuberechnung  der 
Frame  Check  Sequence  und  Paketiibertragung. 

Die  folgenden  Funktionen  sind  fiir  QoS-Eigenschaften  der  Netze  von  Bedeutung:  Benut- 
zerpriorisierung,  Pufferung  und  Paketauswahl  nach  Verkehrsklassen,  um  so  eine  Prioritat 
fiir  bestimmten  Verkehr  zu  erreichen,  maximale  Verzogerungszeit  eines  Paketes  innerhalb 
der  Bridge  und  Bestimmung  der  minimalen  Prioritat  fiir  weiterzuleitende  Pakete. 

Zusammenfassend  kann  man  sagen,  dass  ein  Virtual  Bridged  Local  Area  Network  nach 
diesem  Standard  nur  bestimmte  Prioritaten  fiir  die  Pakete  festlegt.  Diese  werden  dann 
in  den  einzelnen  Bridges  so  ausgewertet,  dass  virtuelle  Bereiche  im  Netz  entstehen.  Uber 
die  maximale  Verzogerung  einer  Bridge  wird  eine  feste  Definition  von  Timeout- Siganlen 
moglich.  Dabei  ist  es  jedoch  moglich,  dass  stark  belastete  Bridges  eine  hohe  Verlustrate 
von  Paketen  aufweist. 


5.5  Zusammenfassung 

In  Wireless  Local  Area  Network  -  Umgebungen  nach  der  IEEE  802.11  sind  beziiglich 
QoS  nur  schwache  Aussagen  moglich.  Der  Standard  bezieht  sich  nur  auf  die  Ebenen  eins 
und  des  ISO/OSI-Referenzmodells.  Im  Standard  werden  nur  Informationen  beziiglich  der 
Reihenfolge  der  Pakete,  der  Vervielfaltigung  von  Paketen  und  der  maximalen  Grofie  des 
Nutzdatums  gemacht.  Andere  Informationen  werden  im  Standard  selbst  nicht  bereitge- 
stellt. 

Mit  einer  Umgebung  nach  dem  Standard  802.1  Q  “Virtual  bridged  LAN“auf  einer  draht- 
losen  Ubertragung  nach  IEEE  802.11werden  zusatzlich  Benutzerpriorisierung  und  Aussa¬ 
gen  iiber  die  maximale  Verzogerungszeit  in  Netzwerkkomponenten  moglich.  Damit  kon- 
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nen  mehr  Aussagen  beziiglich  QoS  getroffen  werden.  Eine  umfangreiche  Auswertung  aller 
Metriken  ist  mittels  RTFM  umzusetzen.  Hier  ist  der  weitgehend  offene  Ansatz  hilfreich. 
Umgebungen  auf  Basis  der  Funkiibertragung  haben  im  Bereich  QoS  erhebliche  Nachteile 
gegenliber  kabelgebundenen  Netzwerken.  Die  Entwicklung  ist  im  Verhaltnis  noch  in  einem 
friihen  Stadium.  Dazu  kommt,  dass  die  technologischen  Moglichkeiten  in  den  bestehenden 
Standards  nicht  ausgenutzt  werden.  Eine  Entwicklung  von  WLAN  ist  in  naher  Zukunft 
besonders  im  Bereich  QoS  zu  erwarten. 
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Kapitel  6 

Moderne  Konzepte  fiir  Sicherheit  in 
Mobilen  Netzen 


Jonathan  Albe 


Wahrend  kabellose  Netzwerke  inzwischen  fiir  jedermann  zuganglich  und  erschwinglich 
sind,  hinkt  die  Sicherheit  dieser  Entwicklung  hinterher.  Nach  der  Einfuhrung  der  WEP- 
Verschliisselung  im  Standard  IEEE  802.11  wurde  dessen  Unsicherheit  sehr  schnell  fest- 
gestellt.  Mit  der  zunehmenden  Verbreitung  von  WLAN  wdchst  seitdem  auch  der  Bedarf 
nach  Sicherheit  in  diesen  Netzen.  Der  Standard  IEEE  802. lli  soil  die  bestehenden  Sicher- 
heitsliicken  in  kabellosen  Netzwerken  schliefien.  Das  in  IEEE  802. lli  enthaltene  TKIP 
Verfahren  sowie  die  Moglichkeit  der  Authentifizierung  durch  IEEE  802. lx  stehen  einem 
Netzbetreiber  bereits  durch  WPA  zur  Verfiigung.  Wird  der  neue  Standard  ratifiziert,  er- 
scheint  damit  das  Verschliisselungsprotokoll  CCMP  auf  dem  Markt,  welches  durch  die 
Verwendung  von  AES  endlich  einen  hoheren  Sicherheitsstandard  verspricht. 

Die  Grundlagen  der  in  IEEE  802.11  und  IEEE  802. lli  verwendeten  Protokolle,  ihre  Star- 
ken  und  Schwachen  sind  Inhalt  dieser  Arbeit.  Auch  protokollunabhangige  Sicherheitsmaft- 
nahmen  werden  erlautert. 
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6.1  Einleitung 


Mit  heute  verfiigbaren  Produkten  ist  es  denkbar  einfach  ein  kabelloses  Netzwerk  (Wireless 
Network)  einzurichten  und  in  Betrieb  zu  nehmen,  so  dass  zwei  oder  mehrere  Teilnehmer 
Daten  kabellos  austauschen  konnen.  Der  Nutzer  muss  lediglich  einen  Zugangspunkt  (Ac¬ 
cess  Point)  montieren  und  diesen  eventuell  an  ein  bereits  vorhandenes  Netzwerk  oder 
zum  Beispiel  einen  DSL-Router  anschliefien.  Auf  den  Stationen  muss  ein  WLAN1  Adap¬ 
ter  installiert  werden,  was  im  giinstigsten  Fall  durch  Plug  &  Play  eine  denkbar  einfache 
Aufgabe  ist.  Aus  Sicht  des  Benutzers  entsteht  so  ein  Netzwerk  ohne  aufwendiges  Verlegen 
von  Kabeln  und  den  damit  verbundenen  Hindernissen.  Der  grofie  Vorteil  des  kabellosen 
Netzwerks  ist  zugleich  sein  grofiter  Nachteil.  Daten  werden  mittels  elektromagnetischer 
Wellen  “durch  die  Luft“  iibertragen.  Die  Ausbreitung  dieser  Wellen  kann  zwar  durch  Hin- 
dernisse  wie  Gebaudeteile  eingeschrankt  werden,  ist  jedoch  generell  nicht  vorhersagbar. 
Und  auf  keinen  Fall  kann  davon  ausgegangen  werden,  dass  sich  ihre  Ausbreitung  auf  das 
eigene  Haus,  das  Bixro  oder  ein  Firmengelande  beschrankt. 

Wahrend  bei  drahtgebundenen  Netzwerken  ein  direkter  physischer  Zugang  zum  Kabel 
gegeben  sein  muss,  konnen  WLAN  Ubertragungen  relativ  einfach,  durch  blofie  Nahe  und 
ggf.  eine  Zusatzantenne  abgehort  und  manipuliert  werden.  Diese  Problematik  ist  hinrei- 
chend  bekannt  und  zog  bereits  einige  Sicherheitsprotokolle  und  Verfahren  nach  sich,  die 
jedoch  keinesfalls  ausreichten  um  Funknetzwerke  zu  schutzen.  Es  herrscht  nach  wie  vor  ein 
starker  Bedarf  an  Sicherheitsmechanismen  im  Zusammenhang  mit  drahtlosen  Netzen.[l] 

Diese  Seminararbeit  betrachtet  die  aktuellen  Entwicklungen  und  zeigt  Vor-  bzw  z.  Nach- 
teile  gegeniiber  vorhergehenden  Sicherheitsmechanismen. 

6.2  Sicherheitsrisiken  und  Angriffsszenarien  fur  Netz- 
werke 


Um  Sicherheitsalgorithmen  und  Protokolle  beurteilen  zu  kdnnen,  ist  es  notwendig  die 
Moglichkeiten  und  Methoden  eventueller  Angreifer  zu  untersuchen.  Im  Folgenden  werden 
einige  grundlegende  Methoden  aufgezeigt  um  in  Netzwerke  einzudringen  oder  diese  zu 
manipulieren.  Angriffswege  die  auf  Social  Engineering ,  also  das  Ausnutzen,  Tauschen 
oder  Erpressen  von  Menschen  abzielen,  sind  nicht  Inhalt  dieser  Arbeit  und  sollen  an 
dieser  Stelle  nicht  betrachtet  werden.  Der  Schwerpunkt  liegt  hier  auf  den  technischen  und 
kryptografischen  Methoden  [2]. 

•  Spoofing  bezeichnet  das  Verbergen  der  eigenen  Identitat  hinter  einer  anderen.  In 
ungeschiitzte  Funknetzwerke  kann  sehr  einfach  eingebrochen  werden,  wenn  der  An¬ 
greifer  eine  vorhandene  MAC2  /  IP  Adresse  ausliest  und  fortan  eigene  Daten  unter 
dieser  Adresse  sendet.  Tools  wie  zum  Beispiel  Kismet  [3]  erleichtern  dieses  Vorgehen. 


1WLAN:  Wireless  LAN,  Funknetzwerk 

2Medium  Access  Control 
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•  Sniffing  beschreibt  das  passive  Mithoren  der  iibertragenen  Daten.  Es  kann  so  auf 
ungesicherte  Daten  zugriffen  werden.  Auch  bei  einer  geschiitzten  Verbindungen  ist 
das  passive  Zuhoren  sinnvoll  um  Informationen  zu  sammeln,  falls  die  Verschliisselung 
bzw.  Schutzprotokolle  angegriffen  werden  sollen. 

•  Session  Hijacking  ist  auch  als  Man-in-the-middle-Attack  bekannt.  Ein  Angrei- 
fer  klinkt  sich  zwischen  zwei  Kommunikationspartner,  leitet  die  Daten  fiber  einen 
eigenen  Rechner  um  und  kann  diese  so  manipulieren.  Solche  Angriffe  sind  z.B.  mit 
gefalschten  Statusmeldungen  moglich,  welche  eine  Umleitung  von  Paketen  veru’rsa- 
chen  konnen. 

•  Replay  Attacken  versuchen  das  Netz,  oder  darin  befindliche  Programme,  durch  ein 
spateres  Neusenden  von  Paketen  zu  beeinflussen.  Hierzu  werden  Pakete  zwischenge- 
speichert  und  zu  einem  spateren  Zeitpunkt  erneut  gesendet  [4]. 

•  DoS3  Attacken  sind  eher  Angriffe  auf  Ressourcen.  als  auf  Sicherheitsmechanismen. 
Sie  werden  zum  einen  der  Vollstandigkeit  wegen  erwahnt,  zum  anderen  werden  sie 
spater  im  Zusammenhang  mit  Abwehrmechanismen  noch  einmal  betrachtet.  Hierbei 
wird  das  Ziel  systematisch  Uberlastet,  um  dessen  Verftigbarkeit  zu  storen. 

•  Brute  Force  Attacken  bezeichnen  ein  Verfahren,  mit  dem  Kennworter  oder  Schlfis- 
sel  durch  systematisches  Probieren  herausgefunden  werden  konnen.  Die  Dauer  dieses 
Vorgangs  hangt  vor  allem  von  der  Rechenleistung  des  Angreifers  und  der  Lange  des 
Passwortes  ab.  Bei  einer  ungiinstigen  Passwortvergabe  oder  Benutzerfehlern  kann 
dieser  Prozess  deutlich  beschleunigt  werden.  Insbesondere  bei  der  Implementierung 
und  Vergabe  von  Passwortern  muss  diese  Technik  bedacht  werden. 


6.3  Sicherheitsanspriiche  fur  Netzwerke 


Aus  der  Betrachtung  moglicher  Bedrohungen  und  eigener  Interessen  entstehen  einige  An- 
spriiche,  welche  an  Sicherheitsprotokolle  zu  stellen  sind.  [5] 

•  Verfugbarkeit  bezieht  sich  im  Zusammenhang  auf  Netzwerkverbindungen  in  erster 
Linie  auf  das  Bereitstehen  der  Verbindung  und  der  Moglichkeit  zu  kommunizieren. 
Im  Rahmen  dieser  Arbeit  bedeutet  Verfugbarkeit  nicht  die  physikalische  Verbindung 
zu  einem  Netzwerkteilnehmer  oder  einem  Zugangspunkt,  sondern  vielmehr  die  Mog- 
lichkeit  diese  auch  ansprechen  zu  konnen.  Ein  Zugangspunkt,  welcher  unter  der  Last 
zu  vieler  Pakete  wegen  eines  DoS-Angriffes  oder  aufgrund  falscher  Anweisungen  ab- 
schaltet,  ist  eben  nicht  mehr  verfiigbar. 

•  Vertraulichkeit  verhindert,  dass  unbefugte  Dritte  Kenntnis  von  Daten  erlangen.  In 
einem  Funknetz  mfissen  hier  leistungsfahige  und  sichere  Algorithmen  zum  Einsatz 
kommen  um  die  Vertraulichkeit  zu  gewahrleisten,  da  die  Ubertragung  selbst  nicht 
geschfitzt  werden  kann. 

•  Integritat  steht  fur  die  Authentizitat  der  iibertragenen  Daten.  Der  Empfanger  muss 
wissen,  ob  die  gesendeten  Daten  genau  die  durch  den  Sender  gesendeten  sind  oder 


3Denial  of  Service:  Nichtverfiigbarkeit  eines  Dienstes 
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ob  Stdrungen  bzw.  bewusste  Veranderung  durch  Dritte  die  Daten  verfalscht  haben. 
Diese  Erkennung  ist  im  Zusammenhang  mit  Vertraulichkeit  besonders  wichtig,  denn 
ein  Erkennen  des  Verlustes  der  Vertraulichkeit  ist  ebenso  wichtig  wie  diese  selbst. 

•  Authentizitat  ist  die  Basis  fur  eine  Zugangskontrolle  und  eng  mit  der  Integritat  ver- 
bunden.  Wahrend  die  Integritat  den  Schutz  der  Daten  an  sich  gewahrleistet,  befasst 
sich  die  Authentizitat  mit  dem  Schutz  von  Quelle  und  Ziel  dieser  Daten. 

•  Zugangskontrolle  schiitzt  Ressourcen  und  Daten,  indem  nur  berechtigte  Benutzer 
Zugang  zu  diesen  erhalten. 

Neben  diesen  elementaren  Sicherheitsanspriichen  ergeben  sich  weitere  Punkte,  die  beim 
Entwurf  von  Sicherheitsprotokollen  fur  Funknetzwerke  bedacht  und  beriicksichtigt  werden 
miissen.  Dazu  gehoren: 

•  Ein  angemessener  Administrationsaufwand:  Weitere  Informationen  zum  Ad- 
ministrationsaufwand  und  Konfigurationsmanagement  enthalt  Kapitel  6.8 

•  Der  Rechenaufwand  der  Zugangspunkte:  ist  oft  beschrankt,  wird  jedoch  fiir 
die  Verschliisselung  der  Nutzdaten  benotigt.  Im  Allgemeinen  muss  davon  ausgegan- 
gen  werden,  dass  grundsatzlich  neue  Verschliisselungsverfahren  auch  neue  Hardware 
benotigen. 

•  Quality  of  Service  in  Wireless  Networks:  Eine  Steigerung  der  Sicherheit  ist 
im  Allgemeinen  mit  mehr  Aufwand  und  einer  Minderung  der  Qualitat  des  Netzes, 
z.B.  der  Reaktionsgeschwindigkeit  oder  der  Bandbreite,  verbunden.  Dieser  Aspekt 
ist  ebenfalls  zu  beriicksichtigen. 


6.4  IEEE  802.11  WEP 


Den  meisten  Funknetzen  liegt  der  IEEE  Standard  802.11  zugrunde.  Insbesondere  das  in 
802.11  enthaltene  WEP  (Wireless  Equivalent  Privacy)  Protokoll  wurde  jedoch  schon  kurz 
nach  seiner  Veroffentlichung  als  zu  schwach  erkannt  und  gebrochen  [6]. 

Aber  auch  wenn  WEP  nicht  als  sicher  gilt,  ist  es  dennoch  weit  verbreitet  und  Grundstein 
fiir  einige  nachfolgende  Sicher heitsprotokolle.  Aus  diesem  Grund  werden  WEP  und  seine 
Schwachstellen  nachfolgend  betrachtet. 


6.4.1  WEP  -  Funktionsweise 


WEP  ist  ein  symmetrisches  Verschliisselungsverfahren,  das  auf  der  RC4  Stromverschliis- 
selung  von  RSA  beruht. 
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Abbildung  6.1:  WEP  -  Verschllisselung 

WEP  Verschliisselung 

Abbildung  6.1  zeigt  die  wesentlichen  Elemente  dieses  Vorgangs[7,  24]. 

Am  Anfang  des  Prozesses  liegen  beim  Sender  der  Klartext  so  wie  der  geheime  Schliissel 
(Shared  Key)  vor.  Je  nach  WEP  Version  hat  der  Schliissel  eine  Lange  von  40  oder  104 
Bit.  Dieser  Schliissel  bildet,  zusammen  mit  dem  24  Bit  langen  Initialisierungsvektor  ei¬ 
ne  Zustandsreihe,  den  Seed.  Die  Verkniipfung  zwischen  Schliissel  und  einem  Vektor,  der 
sich  ausgehend  vom  Initialisierungsvektor  verandert,  soil  verhindern,  dass  gleiche  Nutzda- 
ten  auf  die  gleiche  Weise  verschliisselt  werden.  Die  Erzeugung  des  Initialisierungsvektors 
obliegt  der  jeweils  verwendeten  Hardware/  Firmware. 

Der  Seed  wird  von  einem  Pseudo  Random  Nummer  Generator  (PRNG)  genutzt  um  einen 
Strom  von  Chiffrierbits  zu  verwenden.  Dieser  PRNG  verwendet  zur  Erzeugung  des  Bit- 
stroms  den  RC4  Algorithmus  der  Firma  RSA  [8].  Der  so  entstandene  Bitstrom  wird  zur 
eigentlichen  Verschliisselung  verwendet  und  mit  dem  “Klartext11,  also  den  zu  versendenden 
Nutzdaten,  XOR  verkniipft.  Vor  dieser  Verkniipfung,  der  eigentlichen  Verschliisselung, 
wird  eine  CRC  Berechnung  durchgefiihrt  und  der  ICV  (Integrity  Check  Value)  an  den 
Klartext  angehangt.  Das  Ergebnis  der  Verbindung  zwischen  Klartext  und  den  Chiffrier¬ 
bits  sowie  der  Initialisierungsvektor  werden  anschliefiend  iibertragen. 


WEP  Entschliisselung 

Der  Empfanger  nimmt  die  iibertragenen  Nutzdaten  so  wie  den  Initialisierungsvektor  ent- 
gegen.  Mit  Hilfe  des  iibertragenen  Initialisierungsvektors  und  dem  geheimen  Schliissel, 
welcher  beim  Empfanger  ebenfalls  bekannt  sein  muss,  ist  der  Empfanger  in  der  Lage  den 
gleichen  Seed  und  somit  die  identische  Folge  von  Chiffrierbits  zu  bilden.  Durch  XOR 
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Verkniipfung  kann  der  Empfanger  so  den  Klartext  erlangen.  Mit  Hilfe  des  angehangten 
Integrity  Check  Value  konnen  die  Nutzdaten  auf  Fehler  und  Veranderung  gepriift  werden. 
Abbildung  6.2  zeigt  diesen  Vorgang. 


1 


CRC  Priifung 


Abbildung  6.2:  WEP  -  Entschliisselung 


WEP  -  Designfehler  und  Schwachen 

Bereits  kurz  nach  der  Einfiihrung  von  WEP  wurden  dessen  Schwachen  offensichtlich  [6] 
und  dieses  Protokoll  gebrochen.  Dabei  wurde  gezeigt,  dass  es  auch  in  der  Praxis  relativ 
einfach  ist  WEP  passiv  zu  brechen  [9]. 

Im  Nachfolgenden  sollen  die  grofiten  Fehler  von  WEP  gezeigt  werden.  Fur  einen  moglichen 
Angreifer  ist  hier  die  Seite  des  Senders  interessant.  Abbildung  6.3  markiert  anhand  des 
Verschliisselungsschemas  die  wesentlichen  Schwachstellen. 

1.  Fehlendes  Schliisselmanagement:  WEP  besitzt  keinerlei  Schliisselmanagement.  Der 

geheime  Schliissel,  welcher  fur  die  verschliisselte  Kommunikation  genutzt  wird,  findet 
auch  bei  der  Authentifizierung  mittels  Challenge-Response  Verfahren  seine  Anwen- 
dung.  Wer  also  die  Authentifizierung  bricht,  kann  den  verschliisselten  Funkverkehr 
abhoren  —  und  umgekehrt.  Weiterhin  wird  fur  die  gesamte  Kommunikation  nur  ein 
Schliissel  verwendet.  Eine  Tatsache  die  WEP  in  Verbindung  mit  einem  ohnehin  schon 
kurzen  Schliissel  extrem  angreifbar  macht. 

2.  Erzeugung  des  Initialisierungsvektors:  Bestimmte  schwache  Initialisierungsvek- 

toren  machen  die  Verschliisselung  weiter  angreifbar,  da  sie  wiederum  zu  schwachen 
und  statistisch  auswertbaren  Schliissel-Chiffrierfolgen  fiihren  [11], 

3.  Zu  kurzer  Initialisierungsvektor:  Die  Lange  von  24  Bit  erlaubt  in  Verbindung  mit 

einem  einzigen  festen  Schliissel  eine  maximale  Kombination  von  224  verschiedenen 


128 


Moderne  Konzepte  fur  Sicherheit  in  Mobilen  Netzen 


Abbildung  6.3:  WEP  -  Schwachstellen 


Schliisseln.  Nach  maximal  224  Schliisseln  muss  sich  also  der  Initialisierungsvektor 
wiederholen.  Eine  einfache  Rechnung  zeigt,  dass  bei  Paketgrofien  von  1000  Byte 
pro  Paket  und  einer  Ubertragung  von  11  MBit,  nach  ca.  3,5  Stunden  224  Pakete 
♦  iibertragen  wurden.  Wenn  ein  Netzwerk  nicht  unter  maximaler  Last  lauft  vergroBert 
sich  dieser  Zeitraum,  jedoch  kann  ihn  eine  ungiinstige  Weiterschaltung  des  Initia- 
lisierungsvektors  wieder  verkiirzen.  Es  ist  also  offensichtlich,  dass  wenige  Stunden 
Aufzeichnung  ausreichen  um  verschiedene  Pakete  mit  gleichem  Initialisierungsvektor 
zu  empfangen.  Diese  Kombination  ist  mit  mathematischen  und  statistischen  Metho- 
den  angreifbar4.  Befinden  sich  mehrere  Access  Points  und  Teilnehmer  in  einem  Netz 
sinkt  die  Zeit,  welche  fur  ein  passives  Brechen  von  WEP  benotigt  wird,  mit  dem 
steigenden  Funkverkehr  weiter. 

4.  Schlechte  Implementierung  von  RC4:  In  der  verwendeten  Implementierung  von 

RC4  treten  regelmafiig  schwache  Folgen  von  Chiffrierbits  auf,  welche  besonders  leicht 
gebrochen  werden  konnenfll],  Viele  Tools  zum  Brechen  von  WEP,  z.  B.  AirSnort  [12], 
nutzen  diese  Schwachstelle  aus. 

5.  Unzureichender  Schutz  der  Daten:  Der  Schutz  von  iibertragenen  Daten  wird  in 

WEP  durch  einen  linearen  Algorithmus  bereitgestellt.  Diese  Priifsumme  kann  selbst 
ohne  Kenntnis  des  WEP-Schliissels  manipuliert  werden.  Besitzt  der  Angreifer  erst 
den  WEP-Schliissel,  stellt  der  Integrity  Check  Value  kein  Hindernis  mehr  dar. 


4[7]  demonstriert  einen  Angriff  auf  WEP 
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6.5  WPA  -  Zwischenlosung 

Der  unzureichende  Schutz  durch  WEP  wurde  schnell  erkannt  und  publiziert  [6,  9].  Un- 
geachtet  dessen  herrscht  ein  massiver  Bedarf  an  Sicherheit  in  drahtlosen  Netzwerken  und 
das  Erscheinen  neuer,  verbesserter  Protokolle  verzogert  sich  weiterhin  [13].  Diese  Tatsache 
veranlasste  mehrere  Hersteller  von  WLAN  Produkten  zum  Handeln.  Die  Wi-Fi5  Allianz 
[14],  ein  Zusammenschluss  vieler  grofier  Hersteller  von  WLAN  Produkten,  vertreibt  aus 
diesem  Grund  eine  Zwischenlosung  Namens  WPA  [15].  WPA  steht  fur  Wi-Fi  Protected 
Access  und  kann  auf  Hardware  mit  Wi-Fi  Zertifikat  eingesetzt  werden.  WPA  nutzt  also 
bestehende  Hardware  und  versucht  die  Sicherheitslucken  von  WEP  zu  schlieBen.  Wesent- 
licher  Bestandteil  von  WPA  sind  bereits  fertig  gestellte  Teile  des  Standards  802. Hi,  vor 
allem  das  Protokoll  TKIP  auf  welches  im  Kapitel  6.6.1  naher  eingegangen  wird.  Fur  grofie 
Netzwerke  kann  WPA  auf  weitergehende  Authentifizierungsmethoden  zuriickgreifen,  wel- 
che  im  Kapitel  6.7  beschrieben  werden.  Wichtige  Merkmale  von  WPA  sind:  Abwartskom¬ 
patibilitat  zu  bereits  vertriebenen  Produkten  auf  dem  Markt,  die  Moglichkeit  WPA  durch 
ein  Softwareupdate  auf  vorhandene  Produkte  zu  installieren  und  Aufwartskompatibilitat 
zum  Standard  802.  lli  der  voraussichtlich  Mitte  2004  ratifiziert  wird  [16]. 


6.6  IEEE  802. lli  Neue  Sicherheit 

Die  Sicherheit  in  kabellosen  Netzwerken  soil  mit  der  Einfiihrung  des  neuen  Standards 
802. lli  deutlich  angehoben  werden.  Eine  Anforderung  an  einen  solchen  neuen  Standard 
ist  die  Abwartskompatibilitat,  welche  ein  Betreiben  auf  bereits  vorhandener  Hardware 
moglich  macht  und  letztendlich  eine  schrittweise  Einfiihrung  neuer  Sicherheitsmechanis- 
men  ermoglicht.  Dies  ist  in  so  fern  problematisch,  als  die  Einfiihrung  neuer  Verschliisse- 
lungsalgorithmen  im  Allgemeinen  auch  neue  Hardware  benotigt.  802. lli  enthalt  darum 
zwei  getrennte  Sicherheitsprotokolle.  TKIP  fur  die  Verwendung  auf  bereits  vorhandener 
Hardware  um  eine  Abwartskompatibilitat  zu  gewahrleisten  und  CCMP  als  vollig  neues, 
auf  AES  basierendes  Verschliisselungsprotokoll.  Des  weiteren  stellt  802. lli  die  Moglich¬ 
keit  zur  Verfiigung,  Methoden  zum  Schliisselmanagement  und  zur  Authentifizierung  zu 
nutzen.  Diese  werden  im  Kapitel  6.7  erlautert. 


6.6.1  IEEE  802. lli  -  TKIP 

TKIP  steht  fiir  “Temporal  Key  Integrity  Protocol11  und  ist  die  Zwischenlosung  fur  Ab¬ 
wartskompatibilitat  in  802. lli.  TKIP  kann  durch  Treiberupdates  in  bereits  vorhandene 
Hardware  implementiert  werden.  Aus  eben  diesen  Kompatibilitatsgriinden  ist  der  RC4- 
Algorithmus  weiterhin  der  zentrale  Bestandteil  der  Verschliisselung.  Wesentlicher  Unter- 
schied  zu  WEP  ist  die  Verschliisselung  der  Nachrichten  durch  einen  temporaren  Schliissel 
[17].  Abbildung  6.4  zeigt  die  grobe  Struktur  der  TKIP  Verschliisselung. 

5Wireless  Fidelity 
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Abbildung  6.4:  TRIP  -  Verschliisselung 
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Ausgangspunkt  der  TKIP  Verschliisselung  ist  ein  temporarer  Sitzungsschliissel  (Session 
Key),  welcher  fur  die  laufende  Sitzung  verwendet  wird.  Dieser  Schliissel  wird  vom  Schliis- 
selmanagement  bereitgestellt.  Auf  das  Schliisselmanagement  wird  in  Kapitel  6.7  naher 
eingegangen.  Mit  den  zwei  verschiedenen  Schliisselmixverfahren  und  den  Parametern, 
welche  darauf  Einfluss  nehmen,  sollen  die  Schwachen  des  statischen  Schliissels  und  des 
Initialisierungsvektors  umgangen  werden. 

Schliisselmix  Eins  erzeugt  einen  Temporarschliissel  aus  dem  Session  K6y  und  der  MAC 
Adresse  des  Absenders.  Das  Einbinden  der  eigenen  MAC  Adresse  verhindert,  dass  ver- 
schiedene  Sender  identische  Daten  auf  die  gleiche  Weise  verschliisseln.  Das  .Ergebnis  der 
relativ  aufwendigen  ersten  Phase  kann  zwischengespeichert  werden. 

Die  MIC  Berechnung  schutzt  die  Integritat  der  Nachrichten.  MIC  steht  fur  Message  In¬ 
tegrity  Code  und  wird  mit  der  MAC  Quell-  und  Zieladresse,  einem  MIC  Schliissel  und 
den  eigentlichen  Nutzdaten  berechnet.  Der  MIC  schliefit  die  gesamte  Nachricht,  und  nicht 
einzelne  Pakete,  ein. 

Zum  Schutz  vor  Replay  Attacken  wird  eine  Sequenznummer  in  die  zweite  Schlusselmix- 
prozedur  eingebunden.  Das  Ergebnis  der  zweiten  Schliisselerzeugung  wird  dem  RC4  Algo¬ 
rithms  zugefiihrt.  Die  durch  den  MIC  geschiitzten  Nutzdaten  werden  anschliefiend  durch 
die  Folge  von  Chiffrierbits  aus  dem  RC4  Algorithmus  verschliisselt,  ganz  wie  es  bei  WEP 
der  Fall  ist. 

Gegenmafinahmen 

Der  Schutz  der  Integritat  ist  aufgrund  der  geforderten  Kompatibilitat  nur  eingeschrankt 
moglich.  Die  Beriicksichtigung  der  Rechenleistung  von  Zugangspunkten  verursacht  eine 
kurze  und  somit  angreifbare  Priifsumme.  Um  dennoch  Sicherheit  zu  gewahrleisten,  wur- 
den  im  TKIP  Gegenmafinahmen  implementiert,  welche  die  Verbindung  schiitzen  sollen. 
TKIP  registriert  auf  der  Empfangerseite  Eingriffe  in  geschiitzte  Nachrichten  und  schreibt 
diese  in  ein  LOG.  Stellt  TKIP  innerhalb  von  60  Sekunden  mehrere  Verletzungen  fest, 
so  wird  das  Netz  fur  60  Sekunden  blockiert  und  die  Sitzungsschliissel  so  wie  eventuelle 
Authentifikationen  miissen  erneuert  werden. 

Durch  die  gezielte  Abschaltung  ist  es  theoretisch  moglich,  ein  durch  TKIP  geschiitztes 
Netz  mit  wenigen  geanderten  Nachrichten  lahm  zu  legen.  Diese  Schwache  von  TKIP  wird 
durch  die  Tatsache  relativiert,  dass  ein  WLAN  mit  deutlich  weniger  Aufwand  und  we- 
sentlich  mehr  Paketen  ebenfalls  lahm  gelegt  werden  kann. 

6.6.2  IEEE  802. Hi  -  CCMP 

Wahrend  TKIP  aus  Kompatibilitatsgriinden  einen  Kompromiss  zwischen  alter  Hardware 
und  neuer  Sicherheit  schliefit,  ist  CCMP  ein  ganzlich  neu  designtes  Sicherheitsprotokoll. 
Es  beruht  auf  dem  Advanced  Encryption  Standard  (AES).  CCMP  steht  fur  CTR/  CBC- 
MAC.  Dabei  bezeichnet  CRT  (Counter)  die  Betriebsart  von  AES  und  CBC-MAC  Cipher 
Block  Chainig  -  Message  Authentication  Code.  Die  Bedeutung  dieser  Abkiirzungen  wird 
in  den  nachfolgenden  Absatzen  deutlich. 
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AES  Grundlagen 


AES  ist  ein  Blockchiffre.  Im  Vergleich  zum  Bit  fur  Bit  arbeitenden  RC4  Algorithmus  in 
WEP,  werden  die  Daten  unter  CCMP  blockweise  verschliisselt.  Aus  diesem  Grund  kann 
CCMP  auf  Paketebene  arbeiten,  das  Aufteilen  (Fragmentieren)  von  Nachrichten  kann 
auf  hoherliegenden  Ebenen  stattfinden.  Wahrend  AES  allgemein  in  der  Lage  ist  Blocke 
variabler  Grofie  zu  verschliisseln  wurde  die  Blockgrofie  in  CCMP  auf  128  Bit  festgelegt. 


AES  kann  in  verschiedenen  Betriebsmodi  verwendet  werden.  Im  Modus  ECB  (Electronic 
Codebook)  werden  die  einzelnen  Blocke  direkt  durch  AES  verschliisselt.  Und  auch  wenn 
der  ECB  -  Modus  in  CCMP  nicht  verwendet  wird,  so  soli  er  kurz  aufgezeigt  werden  um  die 
Wahl  des  nachfolgenden  Modus  zu  begriinden.  Abbildung  6.5  zeigt  AES  Verschltisselung 
im  ECB  Modus. 


f  Klartext Klartext  ''N 
Block  Block  J 


f 

AES 

Verschltisselung 

f 

^  Chiffre  Chiffre  ^ 


Abbildung  6.5:  AES  -  Electronic  Codebook 


Die  alternative  Variante  zu  ECB  ist  der  “Counter  Modus“  (CTR).  Hier  wird  statt  der 
Nachricht  ein  Zahlwert  verschliisselt  und  das  Resultat  mir  den  Nutzdaten  XOR  verkniipft. 
Abbildung  6.6  zeigt  AES  im  Counter  Modus  [18].  Folgende  Vorteile  ergeben  sich  durch 
die  Verwendung  des  Counter  Modus  im  Vergleich  zum  ECB  Modus: 

•  Durch  die  XOR  Verkniipfung  am  Ende  spielt  es  keine  Rolle  ob  das  letzte  Paket  genau 
128  Bit  grofi  ist,  ein  eventuelles  Hinzufiigen  von  Fiillbits  entfallt. 

•  Gleiche  Klartextblocke  ergeben  verschiedene  Chiffreblocke.  In  Netzwerken  wo  sich 
bestimmte  Muster,  wie  z.  B.  TCP-Header  oder  bestimmte  Steuerungssignale  wieder- 
holen  ware  dies  ein  Nachteil. 

•  Die  in  der  Grafik  eingerahmten  Schritte,  Berechnen  und  Verschliisseln  des  Zahlers, 
konnen  parallel  ausgefuhrt  werden,  da  sie  nach  dem  Initialisierungswert  nicht  mehr 
vom  Inhalt  der  Pakete  abhangen.  Wie  in  der  Grafik  6.6  ersichtlich,  ist  der  Codier-  und 
Decodiervorgang  exakt  derselbe,  es  ist  keine  unterschiedliche  Hard-  oder  Software 
notig. 
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Codieren  Decodieren 


Abbildung  6.6:  AES  -  Counter 


CCMP  -  Verschliisselung 

Abbildung  6.7  zeigt  den  Verschlusselungsvorgang  im  CCMP  Protokoll  (vereinfacht)  [19]. 
Die  Verschliisselung  geschieht  hier  auf  Paketebene.  MDPU  am  Anfang  und  am  Ende 
bezeichnet  die  ein  und  ausgehenden  Pakete,  die  MAC  Protocol  Data  Unit.  Der  tempora- 
re  Sitzungsschliissel  wird  auch  hier  durch  das  Schliisselmanagement  bereitgestellt  (Siehe 
Kapitel  6.7).  Aus  der  Sequenznummer  und  der  Senderadresse  wird  ein  Nonce  Wert  kon- 
struiert.  Dieser  Nonce  Wert  wird  fur  die  Initialisierung  der  Verschliisselung  und  der  MIC6 
Berechnung  verwendet,  um  eine  wiederholte  Verwendung  des  Sitzungsschlussels  zu  ver- 
hindern. 

Der  CCMP  Header  entspricht  in  etwa  der  Ubertragung  des  Initialisierungsvektors  bei 
WEP  und  TKIP,  es  werden  fur  die  Entschliisselung  relevante  Daten  iibertragen.  Die  Wei- 
tergabe  des  Message  Integritiy  Code  (MIC),  also  einer  Art  Priifsumme,  ahnelt  der  Wei- 
tergabe  bei  WEP  oder  TKIP.  Der  MIC  wird  an  die  unveranderten  Nutzdaten  angehangt 
und  anschliefiend  mit  diesen  verschliisselt.  Die  Berechnung  des  MIC  unterscheidet  sich 
jedoch  grundlegend  von  den  bisherigen. 


CCMP  -  Integritatsschutz 

Fiir  die  Generierung  des  Message  Integrity  Code  wird  die  vorhandene  AES  Verschliisselung 
verwendet  [19].  Die  Nachricht  wird  in  Blocke  aufgeteilt  welche  nacheinander  durch  AES 


6Message  Integrity  Code:  Integritatsschutz  der  Nachricht 
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Abbildung  6.7:  CCMP  -  Verschlusselung 
verschliisselt  werden  wie  Abbildung  6.8  verdeutlicht. 

Dieses  AES-Verschliisselungsverfahren  wird  als  CBC-MAC  bezeichnet.  Neben  der  Nach- 
richt  werden  der  Session  Key  sowie  der  Nonce  Wert  —  und  somit.  die  Absenderadresse  und 
Paketnummer  —  in  den  MIC  eingebunden.  Diese  Zusatzinformationen  garantieren  einen 
eindeutigen  MIC  ohne  Wiederholungen,  welcher  durch  den  Sitzungsschliissel  geschiitzt  ist. 
Diese  Berechnung  ist  eine  Einwegfunktion  und  muss  beim  Empfanger  mit  den  gegebenen 
Ausgangswerten  und  der  entschliisselten  Nachricht  wiederholt  werden.  Stimmt  der  iiber- 
mittelte  und  der  neu  berechnete  MIC  iiberein,  so  wurde  die  Nachricht  nicht  verandert. 


CCMP  Entschliisselung 

Abbildung  6.9  zeigt  den  CCMP  Entschliisselungsvorgang.  Der  erste  Schritt  ist  die  Entnah- 
me  der  Paketnummer  aus  dem  iibertragenen  CCMP  Paket.  Hier  wird,  wie  in  normalem 
Netzwerkbetrieb,  auch  die  Reihenfolge  der  Pakete  gepriift.  Sollte  ein  Angreifer  versuchen 
Pakete  durch  einen  Replay  Angriff  in  anderer  Reihenfolge  einzuspielen,  so  wird  dies  bei 
der  MIC  Uberprufung  auffallen,  da  die  Paketnummer  auch  hier  Einfluss  nimmt.  Wird 
bei  der  Priifung  der  Paketnummer  ein  Fehler  erkannt,  so  wird  das  Paket  verworfen.  Im 
nachsten  Schritt  werden  die  Absenderadresse  und  Paketnummer  aus  dem  empfangenen 
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Abbildung  6.8:  CCMP  -  MIC  Berechnung 


Paket  entnommen  ,und  zur  Konstruktion  des  Nonce  Wertes  verwendet.  Mit  identischer 
Paketnummer  und  Absenderadresse  entsteht  der  identische  Nonce  Wert,  wie  ihn  auch  der 
Absender  beim  Verschlusseln  verwendet  hat.  Mit  Hilfe  des  Nonce  Wertes,  dem  Session  Key 
und  den  Daten  des  empfangenen  Paketes  kann  die  Entschliisslung  durch  AES  erfolgen. 
Wie  Abbildung  6.6  zeigt  ist  dies  der  gleiche  Vorgang  wie  beim  Verschlusseln.  Stimmen 
Session  Key  und  Nonce  Wert  iiberein,  so  verschliisselt  AES  die  gleichen  Counter  und 
erzeugt  ein  Resultat  welches  durch  XOR  Verkniipfung  die  Originaldaten  zuriickliefert. 

Nach  dem  Entschliisseln  liegt  das  Original  MPDU  Paket  und  der  iibertragene  Message 
Integrity  Code  vor.  Wie  oben  beschrieben  wird  abschliefiend  ein  neuer  MIC  berechnet 
um  die  iibertragenen  Daten  zu  verifizieren.  Wird  hier  ein  Fehler  festgestellt  so  wird  das 
empfangene  Paket  verworfen.  Aufgrund  der  deutlich  starkeren  Verschliisselung  des  MIC 
Codes  entfallen  hier  Gegenmafinahmen,  wie  sie  bei  TKIP  vorliegen. 
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Abbildung  6.9:  CCMP  -  Entschliisselung  und  MIC  Prtifung 
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6.7  IEEE  802. lx  -  Authentifizierung  und  Schlussel- 
management 


Sowohl  TKIP  als  auch  CCMP  benotigen  einen  temporaren  Schliissel,  den  Session  Key 
(Sitzungsschliissel).  Dieser  Schliissel  wird  vom  Schliisselmanagement  durch  einen  Haupt- 
schliissel  gebildet.  Dieser  gemeinsame  Hauptschlfissel  gelangt  bei  WEP  durch  Eingabe 
an  den  Geraten  zu  den  Kommunikationsteilnehmern.  Dies  ist  fur  kleine  Netze  durchaus 
sinnvoll  und  am  einfachsten  zu  realisieren.  Mit  einer  wachsenden  Teilnehmerzahl  ist  diese 
Losung  jedoch  nicht  mehr  praktikabel  (Mehr  zum  Konfigurationsmanagement  siehe  auch 
Kapitel  6.8).  Aus  diesem  Grund  besteht  in  IEEE  802. lli  die  Moglichkeit  das  IEEE  802. lx 
Protokoll  fur  die  Authentifizierung  und  Schliisselverteilung  zu  verwenden  [15]. 

IEEE  802.  lx  definiert  eine  allgemeine,  erweiterbare  und  auf  Ports  basierende  Zugangskon- 
trolle,  welche  fur  Funk-  und  Kabelnetzwerke  gleichermafien  giiltig  ist.  802. lx  unterscheidet 
zwischen  zwei  Verbindungsarten.  Kontrollierte  Ports  gestatten  dem  angeschlo$senen  Nut- 
zer  mit  alien  angeschlossenen  Teilnehmern  zu  kommunizieren.  Ein  unkontrollierter  Port 
ist  hingegen  auf  bestimmte  Adressen  und  Bereiche  eingeschrankt  [20] .  Ein  unangemeldeter 
Benutzer  kann  fiber  einen  unkontrollierten  Port  Zugriff  auf  einen  Authentifizierungsser- 
ver  erhalten,  sich  authentifizieren  und  anschliefiend  einen  kontrollierten  Port  verwenden. 
Abbildung  6.10  zeigt  einen  moglichen  Ablauf  des  Verfahrens  mit  einem  Radius  Server. 
Die  mobile  Station  sendet  eine  Anfrage  an  den  Zugangspunkt (Access  Point).  Er  fiber- 


Abbildung  6.10:  802.  lx  Authentifizierung 

nimmt  die  Rolle  des  Authentifizierers  und  vermittelt  zwischen  der  mobilen  Station  und 
dem  Authentifikationsserver.  Der  Zugangspunkt  leitet  die  Authentifizierungsanfrage  an 
den  Authentifikationsserver  weiter.  Dieser  vergleicht  die  Anfrage  mit  den  ihm  bekannten 
Benutzerprofilen  und  gibt  (in  Abbildung  6.10  eingerahmt)  fiber  den  Zugangspunkt  eine 
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Challenge  -  Response  Frage  an  die  mobile  Station  zuriick.  Akzeptiert  der  Authentifika- 
tionsserver  die  Antwort  der  mobilen  Station,  so  informiert  er  den  Zugangspunkt,  so  dass 
dieser  den  entsprechenden  Port  fiir  die  mobile  Station  offnen  kann  und  verteilt  ggf.  die 
Hauptschliissel  an  beide  Kommunikationspartner. 


6.7.1  IEEE  802. lx  -  Kommunikationsprotokolle 

IEEE  802. lx  spezifiziert  die  Benutzung  des  Extensible  Authentication  Protocol7  (EAP). 
EAP  ist  eine  Erweiterung  des  Point  to  Point  Protocol  (PPP).  EAP  kapselt  die  benotigten 
Nachrichten  und  erlaubt  es  so  verschiedene  Protokolle  fiir  den  Authentifizierungsvorgang 
zu  verwenden.  Einige  mogliche,  verschieden  starke  Protokolle  fiir  die  Kommunikation  bei 
der  Authentifizierung  sind  [21]: 

•  EAP-MD5 

Hier  werden  die  iibertragenen  Daten  durch  einen  MD5-Hash  Algorithmus  codiert. 
EAP-MD5  authentifiziert  Sender  und  Empfanger  nicht!  EAP-MD5  verwaltet  stati- 
sche  WEP  Schliissel  und  besitzt  kein  dynamisches  Schliisselmanagement;  es  kann 
also  nur  zur  Identifikation  eines  Benutzers  dienen. 

•  EAP  TLS 

Das  EAP  Transport  Layer  Security  Protocol  ist  im  Wesentlichen  eine  Kombination 
zwischen  EAP  und  SSL.  Es  benotigt  eine  Authentifizierung  auf  Basis  von  Zertifi- 
katen.  EAP  TLS  ermoglicht  neben  dem  benutzerbasiertem  auch  ein  dynamisches 
Schliisselmanagement . 

»  EAP  TTLS 

EAP  -  Tunneled  Transport  Layer  Security  Protocol  ist  eine  Erweiterung  von  EAP 
TLS.  Hier  benotigt  nur  der  Authentifikationsserver  ein  Zertifikat.  Mit  dessen  Hilfe 
wird  ein  Tunnel  zwischen  Authentifikationsserver  und  der  mobilen  Station  aufgebaut, 
durch  welchen  die  Authentifikation  stattfindet.  Der  Benutzer  benotigt  hier  kein  ei- 
genes  Zertifikat.  Aufgrund  dessen  ist  dieses  Protokoll  fiir  eine  Authentifizierung  an 
Hot  Spots  geeignet. 

•  Cisco  Lightweight  Authentication  Extension  Protocol  (LEAP) 

ist  eine  Losung  der  Firma  Cisco.  Hier  authentifizieren  sich  die  mobile  Station  und  der 
Zugangspunkt  gegenseitig.  Das  dynamische  Schliisselmanagement  nutzt  eine  eigene 
WEP-Key-Hash  Funktion. 

•  PEAP  Protected  EAP 

erweitert  EAP,  um  Probleme  bei  der  Verwaltung  der  Zertifikate  zu  losen.  PEAP 
verwendet  ebenfalls  einen  TLS  Tunnel  fiir  die  Authentifizierung.  Die  Verwendung 
von  Upper  Layer  Protokollen  fiir  die  Authentifizierung  ermoglicht  die  Einbindung 
weiterer  Software  fiir  die  Authentifizierung. 

Die  Moglichkeit  verschiedene  Protokolle  fiir  die  Authentifizierung  zu  verwenden,  erlaubt 
es  verschiedene  Authentifizierungsverfahren  zu  implementieren  und  802. lx  dem  eigenen 
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Bedarf  und  der  benotigten  Sicherheit  anzupassen.  So  ermoglicht  EAP-TTLS  eine  Authen- 
tifizierung  auf  Passwortbasis,  wahrend  EAP-TLS  auf  Zertifikaten  mit  einer  Public  Key 
Infrastruktur  beruht  [22].  Auch  eine  Authentifizierung  durch  Smart  Cards  ist  realisierbar 

[23]- 

6.7.2  IEEE  802. lx  Authentifikation  .durch  RADIUS 

Ein  verbreiteter  Authentifizierungsmechanismus  fiir  802. lx  ist  die  RADIUS  -  Authentifi¬ 
zierung.  RADIUS  steht  fiir  Remote  Authentication  Dial-in  User  Service.  RADIUS  stellt 
eine  benutzerbezogene  Zugangsbeschrankung  zur  Verfiigung  [7].  Ein  Radius  Server  ist  ei¬ 
ne  zentrale  Instanz,  welche  in  einem  Netzwerk  Benutzer  verwaltet.  Die  Hauptaufgaben 
dabei  sind  Authentifizierung,  Autorisierung  und  Accounting.  Neben  der  Priifung  wer  im 
Netz  was  tun  darf,  besteht  die  Moglichkeit  die  Nutzung  von  Ressourcen  durch  Benutzer 
zu  erfassen  um  zum  Beispiel  Dienste  abzurechnen. 

Die  Benutzerverwaltung  durch  RADIUS  ist  keine  neue  Idee  fiir  drahtlose  Netze.  Durch 
802.  lx  kann  sie  jedoch  fiir  Funknetze  eingesetzt  werden.  RADIUS  kann  mit  mehreren 
Server  verwendet  werden.  Diese  Server  konnen  in  einem  Verbund  zusammen  agieren  und 
Anfragen  an  jeweils  andere  RADIUS  Server  weiterleiten. 


6.8  Konfigurationsmanagement 


Im  Zusammenhang  mit  der  Sicherheit  in  WLAN,  muss  das  Management  der  Konfigura- 
tion  angesprochen  werden.  In  nahezu  alien  ausgelieferten  WLAN  Komponenten  sind  die 
Sicherheitsmechanismen  standardmafiig  deaktiviert.  Es  ist  leicht  verstandlich,  dass  we- 
der  starke  noch  schwache  Sicherheitsprotokolle  schiitzen  konnen,  wenn  sie  nicht  aktiviert 
werden.  Kapitel  6.9  gibt  dazu  einige  Hinweise.  Insbesondere  die  verschiedenen  im  Ein- 
satz  befindlichen  Sicherheitsprotokolle  und  Verfahren  bergen  einige  Risiken,  auf  welche 
im  Nachfolgenden  eingegangen  werden  soli. 

6.8.1  Mischbetrieb  von  WEP  und  TKIP 

Die  im  Rahmen  dieser  Arbeit  vorgestellten  Verschliisselungsprotokolle  zum  Schutz  einer 
Funkverbindung,  WEP  und  TKIP  (WPA),  konnen  parallel  verwendet  werden.  Insbeson¬ 
dere  neuere  Zugangspunkte  sind  in  der  Lage  zu  erkennen,  welche  Protokolle  die  mobilen 
Stationen  verwenden.  Sie  konnen  sich  dann  entsprechend  anpassen,  so  dass  ein  Mischbe¬ 
trieb  moglich  wird.  Dieser  Mischbetrieb  birgt  einige  Gefahren  [24].  Multicast  und  Broad¬ 
cast  Nachrichten  werden  nach  wie  vor  mit  WEP  verschliisselt,  da  mobile  Stationen  mit 
WEP  die  WPA  Nachrichten  nicht  verstehen  wiirden.  Des  weiteren  muss  davon  ausgegan- 
gen  werden,  dass  zu  WPA  inkompatible  WLAN-Adapter  auch  keine  Authentifizierung 
durch  802. lx  unterstiitzen.  Ein  moglicher  Angreifer  kann  auf  diesem  Weg  die  Authentifi¬ 
zierung  umgehen.  Mit  dem  nicht  vorhandenen  Schutz  durch  WEP  kann  also  das  gesamte 
Netz  kompromittiert  werden.  Es  ist  darauf  zu  achten  einen  Mischbetrieb  moglichst  schnell 
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zu  beenden  und  die  Zugangspunkte  so  zu  konfigurieren,  dass  sie  dann  auch  keine  WEP 
Verbindungen  mehr  akzeptiereu. 


6.8.2  Schlusselmanagement 

Grofiere  Netzwerke  sollten  unbedingt  iiber  ein  automatisohes  Schlusselmanagement  verfii- 
gen.  Aus  diesem  Grund  ist  WEP  fur  solche  Netze  nicht  geeignet.  Bei  der  Verwendung  von 
WEP  muss  an  jedem  Zugangspunkt  und  jedem  WLAN- Adapter  der  gemeinsame  Schliis- 
sel  manuell  eingegeben  werden.  Auch  starkere  Protokolle,  welche  statische  Hauptschliissel 
ohne  Authentifizierung  verwenden,  sind  von  diesem  Problem  betroffen.  Wird  beispiels- 
weise  ein  tragbarer  Computer,  welcher  fiir  dieses  WLAN  konfiguriert  ist,  gestohlen,  so 
ergeben  sich  fatale  Folgen.  Ein  Angreifer  kann  den  Hauptschliissel  des  WLAN  aus  diesem 
Rechner  auslesen  und  hat  fortan  freien  Zugang  zum  Netzwerk  (Im  Fall  von  WEP  ist  der 
WEP-Schliissel  lediglich  ein  Eintrag  in  der  Windows  Registry).  Der  Administrator  die¬ 
ses  WLAN  miisste  nun  alle  Schliissel  an  den  Zugangspunkte  und  alien  WLAN  Adaptern 
austauschen.  Bei  einem  hinreichend  grofien  WLAN  ist  das  mit  einem  immensen  Aufwand 
verbunden,  was  zur  Folge  haben  kann,  dass  es  nicht  getan  wird.  Die  Sicherheit  in  diesem 
Netz  reduziert  sich  folglich  auf  Null. 

Ein  automatisiertes  Schlusselmanagement  / Authentifizierungsverfahren  lost  dieses  Pro¬ 
blem  und  ist  fiir  grofie  Netzwerke  mit  hohem  Sicherheitsbedarf  anzustreben. 


6.8.3  Abschotten  durch  Firewall 

Solange  die  Funkverbindung  zwischen  einem  mobilen  Rechner  und  dem  Zugangspunkt 
als  nicht  sicher  angesehen  werden  kann,  ist  es  sinnvoll,  die  Funkverbindungen  aufierhalb 
einer  Firewall  zu  halten.  Abbildung  6.11  zeigt  eine  Anordnung  ohne  Firewall.  In  dieser 


Abbildung  6.11:  Netzwerkarchitektur  ohne  Firewall 
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Anordnung  erlangt  ein  Angreifer  Zugriff  auf  das  gesamte  Netz  mit  alien  darin  befindli- 
chen  Ressourcen,  falls  er  es  schafft  den  Schutz  der  Funkverbindung  zu  brechen.  Abbildung 
6.12  zeigt  eine  alternative  Konfiguration  [21].  Bei  der  Konfiguration  nach  Abbildung  6.12 


A 

Abbildung  6.12:  Netzwerkarchitektur  mit  Firewall 


befinden  sich  die  Zugangspunkte  mit  den  Funkverbindungen  auBerhalb  einer  Firewall. 
Gelingt  es  einem  Angreifer  den  Schutz  der  Funkverbindung  zu  brechen,  so  befindet  er 
sich  dennoch  auBerhalb  des  zu  schiitzenden  Netzwerkes.  Die  Firewall  kann  den  Angreifer 
auBerhalb  des  Netzes  halten  oder  ihn  durch  Intrusion  Detection8  erkennen.  Rechner  A  auf 
der  Abbildung  hat  natiirlich  keinen  Zugang  mehr  zu  den  Ressourcen  des  Netzes  hinter  der 
Firewall.  Sollte  ein  Rechner  Zugriff  auf  diese  Ressourcen  benotigen,  so  kann  zum  Beispiel 
ein  VPN  Tunnel  durch  die  Firewall  in  das  Netzwerk  etabliert  werden,  wie  die  Abbildung 
6.12  fur  Rechner  B  andeutet.  1st  dieser  Tunnel  durch  eine  ausreichend  starke  Verschliisse- 
lung  geschiitzt,  wird  der  entstehende  Schaden  bei  einem  Angriff  auf  die  Funkverbindung 
zu  Rechner  B  begrenzt.  Je  nach  eingesetztem  Sicherheitsprotokoll  konnte  der  Angreifer 
z.  B.  Rechner  A  angreifen  und  vielleicht  Zugriff  auf  das  Internet  erlangen.  Zwischen  dem 
Angreifer  und  dem  zu  schiitzenden  Netzwerk  stehen  jedoch  immer  noch  die  starke  VPN 
Verschliisselung  und  die  Firewall. 
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6.9  MaBnahmen  zur  Erhohung  der  Sicherheit  in  Netz- 
werken 


Wie  die  bisherigen  Ausfiihrungen  zeigen,  ist  Sicherheit  in  kabellosen  Netzwerken  keine 
Selbstverstandlichkeit.  Sicherheit  ist  jedoch  immer  eine  Frage  des  Aufwandes  und  der  zu 
schutzenden  Daten  und  Ressourcen.  Fur  Anwender  mit  hohem  Sicherheitsbedarf  kom- 
men  Funknetze  entweder  iiberhaupt  nicht,  oder  nur  mit  umfassenden  organisatorischen 
Mafinahmen  und  starken  Verschliisselungsalgorithmen  in  Frage. 

Die  starke  Nachfrage  und  der  wachsende  Markt  fur  Wireless  Networks  zeigen  jedoch,  dass 
ungeachtet  der  Sicherheitsprobleme,  ein  hohes  Interesse  an  dieser  Technologie  besteht. 

In  diesem  Kapitel  sollen  einige  Mafinahrnen  erlautert  werden,  welche  das  Aufspiiren  und 
Kompromittieren  von  Funknetzwerken  erschweren  und  somit  die  eigene  Sicherheit  erhohen 
[24]. 

•  Aktivieren  der  Schutzmafinahmen 

Aktivieren  Sie  die  vorhandenen  Schutzmafinahmen  ihrer  Netzwerkkomponenten.  Auch 
wenn  WEP  leicht  zu  brechen  ist,  erfordert  es  noch  einen  Aufwand  und  einige  Com- 
puterkenntnisse. 

•  SSID9  abschalten  oder  umbenennen 

Falls  es  technisch  und  organisatorisch  moglich  ist,  sollte  der  SSID  -  Broadcast  de- 
aktiviert  oder  zeitlich  begrenzt  werden,  so  dass  ein  Firmennetzwerk  z.  B.  nur  in  der 
Arbeitszeit  aktiv  ist.  Sollte  die  SSID  weiterhin  ausgestrahlt  werden,  sollte  sie  um- 
benannt  werden,  so  dass  keine  Riickschliisse  auf  den  Inhalt  des  Netzes  gewonnen 
werden  konnen 

*•  MAC  Filter ung  einrichten 

Die  Zugangspunkte  so  zu  konfigurieren,  dass  sie  nur  authorisierte  MAC  Adressen 
akzeptieren,  erfordert  einen  gewissen  Aufwand,  steigert  jedoch  den  Aufwand  welcher 
erforderlich  ist  um  in  ein  WLAN  einzubrechen. 

•  Statische  Schliissel  periodisch  wechseln 

Werden  statische  Schliissel  in  einem  WLAN  verwendet,  so  sind  diese  regelmafiig  zu 
wechseln,  um  das  WLAN  sicher  zu  halten.  Bei  der  Passwortwahl  sind  die  entsprechen- 
den  Regeln  —  Lange  und  Zeichenvielfalt  —  zu  beachten.  Bei  manchen  Zugangspunk¬ 
te  sind  Default-Passworter  fur  den  Administrationszugriff  eingestellt.  Diese  miissen 
unbedingt  geandert  werden.  Zugangspunkte,  welche  nur  durch  den  Kabelzugang  kon- 
figuriert  werden  konnen,  bieten  eine  noch  grofiere  Sicherheit. 

•  Technische  Mafinahrnen 

* 

Wenn  moglich  sollte  die  Leistung  der  Zugangspunkte  so  weit  reduziert  werden,  dass 
nur  der  gewiinschte  Bereich  Zugriff  auf  den  Acess  Point  hat.  Das  Auffinden  des 
Netzwerkes  wird  so  erschwert. 

•  DHCP  abschalten 

Wenn  die  automatische  Vergabe  von  IPs  nicht  benotigt  wird,  sollte  sie  deaktiviert 
werden.  Eine  statische  IP- Vergabe  mit  moglichst  kleinem  Adressraum  verhindert  eine 
automatische  Zuweisung  einer  giiltigen  IP  an  einen  Angreifer. 
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•  Firmware  Upgrades  durchfuhren 

Wenn  moglich  sollten  Updates  von  Treibern  und  Software  auf  den  WLAN-Komponenten 
durchgefiihrt  werden,  da  dies  ebenfalls  die  Sicherheit  erhohen  kann.  Hierbei  ist  aller- 
dings  auf  Kompatibilitat  der  Komponenten  untereinander  zu  achten. 


6.10  Zusammenfassung 

In  den  letzten  Jahren  fanden  kabellose  Netze  eine  starke  Verbreitung.  Allerdings  wurde 
schnell  klar,  dass  die  ersten  Sicherheitsprotokolle,  insbesondere  WEP,  keinen  nennenswer- 
ten  Schutz  bieten.  Es  wurden  und  werden  Schritte  unternommen,  mehr  Sicherheit  fur  Fun- 
knetzwerke  zu  bieten.  Mit  der  Einfuhrung  des  Standards  IEEE  802.  lli  wird  die  Sicherheit 
in  Funknetzwerken  einen  grofien  Sprung  nach  vorne  machen.  Die  AES-Verschliisselung,  auf 
welcher  der  Standard  beruht,  hat  sich  jahrelang  bewahrt  und  wird  Angriffe  auf  kabellose 
Netzwerke  massiv  erschweren.  Leider  lasst  der  Standard  im  Moment  noch  auf  sich  war- 
ten.  Aber  auch  die  WPA  Zwischenlosung  mit  TKIP  und  Authentifizierungsmafinahmen 
steigert  die  Sicherheit  im  WLAN  im  Vergleich  zum  unsicheren  WEP  betrachtlich. 

Ein  Problem,  welches  Angreifern  allerdings  noch  lange  Zeit  Tiir  und  Tor  offnen  wird, 
ist  das  mangelnde  Sicherheitsbewusstsein  vieler  Betreiber  von  Funknetzwerken.  Solan- 
ge  mogliche  Sicherheitsmechanismen  nicht  aktiviert  und  konfiguriert  werden,  kann  ein 
WLAN  nicht  sicher  sein. 

Totale  Sicherheit  wird  es,  auch  im  WLAN,  vermutlich  nie  geben.  Ein  sicherheitsbewusster 
Nutzer  hat  mit  WPA  oder  auch  VPN  und  einer  verniinftigen  Konfiguration  jedoch  die 
Moglichkeit  sein  WLAN  gut  zu  schiitzen.  Mit  dem  Erscheinen  von  IEEE  802. lli  und 
entsprechenden  Geraten  steigen  diese  Moglichkeiten  weiter,  sofern  der  Standard  nicht 
gravierende  Designfehler  aufweist. 
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Kapitel  7 

Intrusion  Detection  in  mobilen 
Netzwerken 


Lars  Langer 


Im  letzten  Jahrzehnt  gewann  die  Intrusion  Detection  fortwahrend  an  Bedeutung.  Parallel 
dazu  keimte  die  mobile  Umgebung  fur  Netzwerke  auf.  Deshalb  entstanden  fur  die  Intrusion 
Detection  immer  neuere  Herausforderungen  und  Probleme,  die  geldst  werden  mussten.  Mit 
einigen  Losungsansatzen  stehen  den  Netzwerkbetreibem  auch  hierfiir  bereits  einige  Mog- 
lichkeiten  offen,  mit  Intrusion  Detection  ihre  mobilen  Netzwerke  und  Endgerate  sicherer 
zu  gestalten.  Mit  der  zunehmenden  Effektivitat  von  Intrusion  Detection  Systemen,  nimmt 
auch  die  Zahl  der  Interessenten  zu,  die  mit  dieser  zweiten  Verteidigungslinie  beabsichti- 
gen,  sich  selbst  oder  ihren  Kunden  einen  hoheren  Grad  an  Sicherheit  zu  gewahrleisten. 
Trotz  dessen  wird  Intrusion  Detection  immer  nur  eine  Erganzung  zu  auch  anderweitig 
geschiitzten  Netzwerken  bleiben,  und  niemals  die  Firewall  ersetzen  konnen. 

Inhalt  dieser  Arbeit  soil  sein,  auch  dem  weniger  sachkundigen  Leser  nahe  zu  bringen, 
was  Intrusion  Detection  leisten  kann,  indem  zunachst  die  dazu  angewandten  Methoden 
skizziert  werden  gefolgt  von  den  Moglichkeiten  ihren  Einsatz  zu  variieren.  Wichtig  ist 
ebenso,  darzulegen  welche  Ansatze  dem  Benutzer  bereits  geboten  werden  Intrusion  Detec¬ 
tion  in  drahtloser  Umgebung  einzusetzen  und  damit  verbundene  Herausforderungen  und 
Probleme  zu  bewaltigen. 
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Mobile  Netzwerke  breiten  sich  immer  mehr  aus.  Damit  sie  auch  in  sicherheitsempfind- 
lichen  Bereichen  eingesetzt  werden  kdnnen,  miissen  sie  ahnlich  hohen  Sicherheitsanfor- 
derungen  geniigen  wie  drahtgebundene  Netze.  Ein  wichtiges  Werkzeug  um  die  Integritat 
eines  Netzwerkes  sicher  zu  stellen  sind  Intrusion  Detection  Systeme.  Sie  iiberwachen  stan- 
dig  den  Datenverkehr  und  versuchen  Anomalien  und  Angriffe  aufzuspiiren  und  daraufhin 
angemessene  Reaktionen  einzuleiten.  Diese  Arbeit  stellt  das  Konzept  von  Intrusion  Detec¬ 
tion  Systemen  vor  und  zeigt  mogliche  Klassifizierungen  auf.  Anhand  von  auf  dem  Markt 
befindlichen  Losungen  stellt  die  Seminararbeit  weiterhin  dar,  in  wie  weit  diese  auch  fur 
drahtlose  Netzwerke  einsetzbar  sind. 


7.2  Intrusion  Detection  und  angewandte  Methoden 


In  diesem  Kapitel  wird  nach  einem  kurzen  allgemeinen  Uberblick  auf  die  angewandten 
Methoden  der  Intrusion  Detection  eingegangen  und  im  folgenden  seine  Anwendung  auf 
bestimmte  Arten  von  Angriffen  vorgestellt. 


7.2.1  Allgemeines 


In  den  letzten  Jahren  werden  Informationssysteme  zunehmend  vernetzt.  Da  sich  die  Be- 
drohungslage  im  Internet,  aber  auch  innerhalb  eines  Firmennetzwerkes  (Intranet,  LAN 
usw.)  verschlechtert,  erfordert  die  Systemsicherheit  ein  hoheres  Mafi  an  Beriicksichtigung. 
Kein  noch  so  fortschrittliches  System  kann  einen  liickenlosen  Schutz  garantieren.  Des- 
halb  finden  neben  bereits  obligatorisch  eingesetzten  Firewalls  auch  Intrusion  Detection 
Systeme  (IDS)  immer  weitere  Verbreitung.  Doch  was  ist  Intrusion  Detection  (ID)  iiber- 
haupt?  Hierbei  handelt  es  sich  um  die  Moglichkeit  einer  Zweite  Linie  der  Verteidigung 
hinter  derjenigen  der  Firewalls  und  Zugangskontrollen  etc.  aufzubauen.  Man  mochte  et- 
was  unternehmen  konnen,  wenn  die  bisherigen  Sicher heitsvorkehrungen  umgangen  worden 
sind.  Intrusion  Detection  bietet  die  Moglichkeit  unautorisiertes  Modifizieren  von  Daten 
eines  beobachteten  Systems  oder  des  Datenaustauschs  zwischen  mehreren  Systemen  auf- 
zuspuren  und  angemessene  Mafinahmen  zu  ergreifen.  Problematisch  ist  aufierdem,  dass 
die  Bedrohung  das  System  nicht  nur  von  Aufien  durch  Hacker,  Script  Kiddies,  Terroris- 
ten,  Spione  oder  bosartigem  Code  von  Malware  gefahrdet  ist,  sondern  auch  von  Innen. 
Gemeint  sind  damit  Mitarbeiter,  die  bosartig  oder  durch  Erpressung  versuchen  dem  Sys¬ 
tem  Schaden  zuzufiigen,  die  vielleicht  eine  mangelnde  Ausbildung  erhalten  haben  oder 
durch  die  sich  in  der  Konfiguration  des  Intrusion  Detection  Systems  Fehler  eingeschlichen 
haben.  Intrusion  Detection  Systeme  sind  ein  relativ  junges  Forschungsgebiet,  zu  dem  es 
kaum  herstellerunabhangige  Daten  gibt  und  es  auch  trotz  der  enormen  Fortschritte  im 
letzten  Jahrzehnt  noch  immer  nicht  den  angemessenen  Einzug  in  die  Lehrbiicher  geschafft 
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hat.  Anfangs  war  Intrusion  Detection  auch  nur  ein  Versuch  die  Auditdaten  eines  Main¬ 
frames  auf  ein  kompaktes  aussagekraftiges  Niveau  zu  reduzieren[2].  Auditdaten  ist  der 
Begriff,  mit  dem  man  bei  Intrusion  Detection  Systemen  generierte  Prtifdaten  beschreibt. 
In  der  ID  versucht  man  insbesondere  mit.  2  Methoden  nach  einem  eventuellen  Eingriff  zu 
suchen.  Im  Folgenden  wird  auf  diese  Methoden  spezieller  eingegangen. 


7.2. 2  Anomaly  Detection 


Bei  dieser  Methode  geht  man  von  der  Annahme  aus,  dass  eine  Bedrohung,  sei  es  ein 
Angreifer,  Malware  oder  andere  unautorisierte  Modifikation  der  Systemdaten,  durch  seine 
Aktionen  das  Verhalten  des  Systems  so  beeinflusst,  dass  es  von  seinem  normalen  Verhalten 
abweicht.  Aufgabe  dieser  Methode  ist  nun  diese  Abweichungen  aufzuspuren  und  darauf 
entsprechend  zu  reagieren.  Die  Vorgehensweise  ist,  dass  vom  System  Messdaten  gesammelt 
werden  und  zu  statistischen  Profilen  (behaviour  profiles)  zusammengefasst  werden.  Hier- 
bei  besteht  auch  die  Moglichkeit  der  Eingrenzung  der  Detection  auf  ein  Teilsystem  oder 
einen  User.  Im  Folgenden  wird  darauf  eingegangen,  dass  diese  Vorgehensweisen  sowohl 
programmiert  als  auch  vom  ID  System  selbst  erlernt  sein  konnen[l], 

Selbstlernende  Systeme 

Diese  Systeme  werden  in  drei  Kategorien  unterschieden.  Das  Unterscheidungskriterium 
sind  die  Mittel  der  Beschreibung  des  gutartigen  Verhaltens. 

Rule  Modelling: 

Hierbei  wird  zunachst  der  auftretende  Verkehr  der  Daten  studiert.  Es  folgt  der  Versuch 
die  normalen  Operationen  durch  das  Aufstellen  von  Regeln  zu  beschreiben.  Bei  einem 
Regelverstofi  wird  Alarm  ausgelost.  Auf  mogliche  weitere  Reaktionen  des  Systems  wird 
im  Kapitel  3.3  genauer  eingegangen. 

Descriptive  Statistics: 

Nach  einer  Sammlung  von  einfachen  Grenzwerten  innerhalb  der  systemtypischen  Opera¬ 
tionen  wir  daraus  ein  Mittelwert  gebildet.  Daraufhin  folgt  die  Berechnung  der  Standard- 
abweichungen.  Schliefilich  kontrolliert  man  durch  einen  daraus  gebildeten  Abstandsvektor 
(distance  vector)  die  Abweichungen,  die  im  System  vorkommen.  Bei  einer  Distanz,  die 
nicht  im  Toleranzbereich  liegt,  wird  ein  Alarm  ausgelost. 

Kiinstliches  neurales  Netz: 

Das  ANN  -  Netz  (artificial  neural  network)  wird  zunachst  mit  dem  normalen  Verkehr 
gefiittert.  Daraus  versucht  es  Strukturen  und  Muster  (pattern)  zu  deuten  und  zu  erkennen. 
Beim  Einsatz  des  ANN  wird  das  aktuelle  Muster  mit  den  studierten  verglichen.  Sind  die 
Strukturen  verschieden  kommt  es  zum  Alarm. 
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Programmierte  Systeme 

Programmierte  Systeme  werden  in  zwei  Kategorien  unterschieden.  Der  gravierende  Un- 
terschied  liegt  bei  der  Vorgehensweise  zur  Umschreibung  von  akzeptablem  Verhalten. 

Statistics: 

Man  bildet  ein  statistisches  Profil  des  normalen  Verhaltens  durch  die  Speicherung  und 
Sammlung  einfacher  Statistiken.  Moglichkeiten  hierfiir  waren  die  Anzahl  von  fehlgeschla- 
genen  Logins,  die  Anzahl  der  Netzwerkverbindungen  oder  auch  die  Anzahl  von  Komman- 
dos  mit  negativer  Antwort  (error  return).  Es  bietet  sich  an,  Alarm  zu  geben,  wenn  die 
Anzahl  einen  festgelegten  Wert  uberschreitet. 

Default  Deny: 

Die  Idee  davon  ist,  die  Umstande,  unter  denen  das  System  als  gutartig  eingestuft  wird,  also 
alle  sicherheitskonformen  Zustande,  explizit  anzugeben.  Damit  entsteht  eine  klare  Uber- 
einstimmung  mit  einer  Sicherheitspolitik  mit  vorgegebener  Ablehnung  jeglichen  anderen 
Verhaltens. 

Diese  Vorgehensweisen  sind  bzw.  enthalten  strikte  Anweisungen  fiir  das  System,  was  ein 
nor  males  Verhalten  sein  darf.  Jedwede  Abweichung  von  diesem  erlaubten  Verlauf  ist  in- 
akzeptabel  und  fiihrt  zu  einem  Alarm.  Problematisch  hierbei  ist  es,  dass  eine  Abweichung 
vom  System  kein  bosartiges  Verhalten  sein  muss,  sondern  lediglich  Aktionen  von  neuem 
normalem  Verhalten  sein  konnten.  Deshalb  kommt  es  in  Anomaly  Detection  Systemen  zu 
einer  nicht  unerheblichen  Anzahl  von  Fehlalarmen. 

Uberblick 

Dieser  Uberblick  stellt  kurz  das  Pro  und  Contra  gegeniiber. 

Vorteile: 

Anomaly  Detection  Systeme  sind  unabhangig  von  einer  Signaturdatenbank.  Deshalb  ist 
es  in  der  Lage  alle  moglichen  Angriffe  zu  erkennen,  ganz  gleich,  ob  der  Angriff  bereits 
bekannt  ist,  oder  auf  einer  neuen  Taktik  beruht. 

Nachteile: 

Der  rechentechnische  Aufwand  ist  hoher  als  bei  der  folgenden  Methode  (Signature  De¬ 
tection).  Darunter  leidet  die  Performance  des  Systems.  Die  Fehlalarmrate  dieses  Systems 
ist  sehr  hoch,  und  neue  Aktivitaten  konnen  nicht  von  Angriffen  und  anderen  Anoma- 
lien  Unterschieden  werden.  Aufgrund  dieser  hohen  Anfalligkeit  fiir  (Fehl  )Alarme  sind 
Tauschungen  und  Denial  of  Service  Angriffe  mit  geringem  Aufwand  moglich.  Fiir  den 
Administrator  ist  diese  Tatsache  sehr  arbeitsaufwendig  und  wenig  tragbar. 
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7.2.3  Signature  Detection 


Diese  Methode  geht  davon  aus,  dass  ein  bestimmter  Angriff  nach  einem  ganz  bestimmten 
Muster  folgt.  Verschiedenartige  Angriffe  haben  dementsprechend  verschiedene  Muster. 
Beispielsweise  verursacht  eine  synchronization-flood  Attacke  viele  unbeantwortete  TCP 
Synchronisationspakete.  Solche  Strukturen,  genannt  Angriffssignatur  (attack  signature), 
versucht  das  Signature  Detection  System  in  den  Auditdaten  zu  finden.  Vorraussetzung 
dafiir  ist  jedoch,  dass  der  Angriff  bereits  zuvor  bekannt  geworden  ist,  und  seine  Signatur 
in  der  Datenbank  des  gegenwartigen  ID  Systems  enthalten  ist.  Im  Bereich  der  Signature 
Detection  Methoden  gibt  es  derzeit  noch  einen  grofien  Nachholbedarf  bei  den  selbstler- 
nenden  Systemen.  Es  werden  derzeit  nur  programmierte  Vorgehensweisen  angewandt,  die 
im  Folgenden  erklart  werden  [1]. 

Programmierte  Systeme 

Programmierte  Systeme  in  der  Signature  Detection  konnen  in  vier  Kategorien  unterschie- 
den  werden.  Im  Gegensatz  zu  Anomalie  Detection  geht  es  hierbei  um  die  Unterscheidung 
der  Mittel  zur  Beschreibung  des  bosartigen  Verhaltens. 

State  Modelling: 

Bei  dieser  Vorgehensweise  existieren  mehrere  Zustande,  die  einen  Alarm  auslosen  konnen. 
Wichtig  dabei  ist,  dass  jeder  dieser  Zustande  im  beobachteten  Bereich  existent  gewesen 
sein  muss,  damit  man  mit  Sicherheit  feststellen  kann,  dass  ein  Eingriff  stattgefunden  hat. 
Die  Anordnung  der  Zustande  kann  im  giinstigsten  Fall  als  einfache  Kette  ablaufen,  es  sind 
jedoch  auch  verzweigtere  Gebilde  moglich,  beispielsweise  Baumstrukturen  oder  Petrinetze. 

Expert  System: 

Die  Entscheidung  eines  Experten  Systems  basiert  auf  einer  Menge  von  komplexen  gegebe- 
nen  Regeln.  Diese  Vorgehensweise  ist  am  angemessensten,  wenn  im  System  standig  neue 
Fakten  und  zu  priifende  Ereignisse  stattfinden.  Dadurch,  dass  es  das  Experten  System 
auch  ermoglicht  selbstmodifizierenden  bosartigen  Code  eines  Angriffs  aufzuspiiren,  ist  es 
eine  der  machtigsten  Mdglichkeiten  der  Intrusion  Detection.  Weiterhin  bietet  es  durch 
seine  Regelbasiertheit  einen  hohen  Grad  an  Flexibilitat.  Doch  diese  Vorteile  fordern  auch 
einen  Preis.  Experten  Systeme  verzeichnen  hohe  Verluste  in  der  Performance  des  kontrol- 
lierten  Systems,  nicht  zuletzt  aufgrund  der  Komplexitat  der  Regeln. 

Simple  rule  based: 

Diese  Systeme  ahneln  den  machtigeren  Experten  Systemen.  Da  hier  mehr  Wert  auf  die 
Performance  des  Systems  gelegt  wurde,  verzichtet  man  darauf,  solch  komplexe  Regeln  zu 
verwenden. 

String  Matching: 

Hierbei  handelt  es  sich  um  ein  Verfahren,  das  die  Bitfolgen  bzw.  den  Text  der  zwischen 
mehreren  Systemen  iibermittelt  wird  zu  durchsuchen  um  eventuelle  kleinere  Bitfolgen  und 
Strings  darin  zu  finden,  die  einem  Angriff  aus  der  Datenbank  zugeordnet  werden  konnen. 
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Bei  Signature  Detection  Systemen  sind  Abweichungen,  die  keinem  bekannten  Angriff  ent- 
sprechen,  akzeptabel.  Es  soil  darauf  hingewiesen  sein,  dass  man  in  anderer  Literatur  mog- 
licherweise  den  BegrifF  Misuse  Detection  finden  kann,  der  dem  Begriff  der  Signature  De¬ 
tection  entspricht. 

Uberblick 

Hier  werden  Vor-  und  Nachteile  zusammenfassend  dargestellt. 

Vorteile: 

Ein  Signature  Detection  System  ist  im  Allgemeinen  recht  schnell  und  findet  zuverlassig 
bekannte  Angriffssignaturen.  Dadurch  gilt  es  weithin  als  das  starkere  der  beiden  Metho- 
den.  Besonders  im  Bereich  der  Online-Uberwachung  des  Verkehrs  in  Netzwerken  wird 
vorwiegend  auf  Signature  Detection  zuriickgegriffen.  Aufierdem  kommt  es  bei  fehlerfreier 
Analyse  der  Auditdaten  zu  keinem  Fehlalarm,  da  nur  bekannte  Angriffssignaturen  Alarm 
auslosen  konnen. 

Nachteile: 

Da  die  aufzuspiirenden  Angriffe  komplett  bekannt  und  bereits  analysiert  sein  miissen, 
damit  die  attack  signature  in  der  Datenbank  zur  Verfiigung  steht,  ist  diese  Methode  ab- 
hangig  von  dieser  Datenbank  und  von  standigen  Updates.  Unbekannte  und  neue  Angriffe 
konnen  bei  Signature  Detection  gefahrlich  werden,  da  sie  nicht  erkannt  werden  konnen. 


7.2.4  Compound  Detection 


Hierbei  handelt  es  sich  lediglich  um  ein  System,  dass  von  der  Methode  der  Signature 
Detection  abgeleitet  wurde.  Der  Begriff  ’signature  inspired’  ist  daher  auch  haufig  diesbe- 
ziiglich  in  anderer  Literatur  zu  finden [1].  Tatsachlich  jedoch  zieht  dieses  Verfahren  beide 
Methoden  zu  Rate,  sowohl  Anomaly  Detection  als  auch  Signature  Detection.  Eine  mogli- 
che  Anwendung  ware  wie  folgt[4].  Dieses  ID  System  sucht  im  beobachteten  Bereich  nach 
Anomalien.  Sobald  es  solche  Abweichungen  vom  normalen  Verhalten  gibt,  werden  die 
betroffenen  Daten  nach  attack  signatures  durchsucht.  Somit  konnen  auch  unbekannte 
Angriffe  einen  Alarm  auslosen,  und  es  besteht  die  Moglichkeit  verschiedene  Alarmstufen 
zu  integrieren.  Dieses  Verfahren  bietet  demnach  eine  deutlich  bessere  Chance  wirklich  in- 
teressante  Ereignisse  zu  entdecken,  da  sowohl  ein  Vergleich  zwischen  aktuellem  Verhalten 
und  normalem  Verhalten,  als  auch  zwischen  aktuellem  Verhalten  und  bosartigem  Verhal¬ 
ten  gemacht  wird.  Andererseits  besteht  auch  die  Moglichkeit  durch  das  Anwenden  beider 
Methoden  eine  bessere  Abstimmung  zwischen  normalem  und  bosartigem  Verhalten  zu  er- 
zielen,  und  in  Strukturen  oder  Regeln  festzuhalten.  Ublicherweise  sind  solche  Verfahren 
selbstlernend[l]. 
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7.2.5  Arten  der  Angriffe 


Um  kategorisieren  zu  konnen  bei  welchen  Angriffen  welche  Methode  geeignet  scheint  wird 
nun  vorgestellt,  in  welche  drei  Arten  Angriffe  unterschieden  werden  konnen[l].  Im  Folgen- 
den  sind  diese  Arten  danach  geordnet,  welche  Schwierigkeit  sie  beim  Detektieren  bereiten. 

Well  Known  Intrusions: 

Angriffe  dieser  Art  sind  sehr  leicht  zu  finden.  Sie  sind  bereits  gut  bekannt  und  demnach 
sind  deren  Angriffsstrukturen  in  jeder  aktuellen  Datenbank  eingetragen.  Der  Grand  dafiir 
liegt  einmal  in  der  Einfachheit  der  Angriffssignatur,  die  zudem  von  Angriff  zu  Angriff 
auch  kaum  oder  keine  Variationen  benutzen.  Zum  anderen  liegt  es  daran,  dass  Angriffe 
dieser  Art  meist  ein  ganz  bestimmtes  Sicherheitsloch  benutzen,  wodurch  die  Lokalisierbar- 
keit  erheblich  vereinfacht  wird,  ebenso  die  Abwehr  durch  eventuelle  Updates,  die  dieses 
Loch  schlieBen.  Aufgrund  der  gegebenen  attack  signature  wird  hierfiir  Signature  Detection 
bevorzugt. 

Generalizable  Intrusions: 

Diese  Eingriffe  ins  System  kann  man  mit  etwas  mehr  Aufwand  auch  noch  finden.  Sie  haben 
haufig  komplexere  Variationen,  beispielsweise  in  Form  von  variierenden  Petrinetzen,  und 
benutzen  nicht  nur  ein  Sicherheitsloch,  sondern  greifen  durch  mehrere  auf  einmal  an.  Das 
macht  sie  etwas  schwerer  zu  entdecken,  aber  mit  Compound  Intrusion  Detection  und 
kombinierter  Intrusion  Detection  bestehen  gute  Chancen,  dass  man  sie  aufspiiren  kann 
urh  darauf  zu  reagieren. 

Unknown  Intrusions: 

Es  kann  vorkommen,  dass  diese  Angriffe  noch  nicht  ausreichend  studiert  worden  sind, 
oder  komplett  unbekannt  sind.  Solch  ein  Angriff  nutzt  in  der  Regel  ein  Sicherheitsloch, 
das  zuvor  noch  nicht  gefunden  oder  nicht  weiter  beachtet  wurde.  Dadurch  sind  sie  sehr 
schwer  zu  finden.  Lediglich  Anomalien  konnen  auf  ihre  Existenz  hinweisen,  weshalb  man 
auch  nur  Anomaly  Detection  gegen  diese  Angriffe  einsetzen  kann. 


7.3  Moglichkeiten  des  Einsatzes  von  Intrusion  Detec¬ 
tion 


Dieses  Kapitel  beschaftigt  sich  damit,  auf  welche  Art  ein  Intrusion  Detection  System 
eingesetzt  werden  kann. 
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7.3.1  Netzwerkbasiert  und  Rechnerbasiert 


Ein  ID  System  kann  zur  Uberwachung  von  Netzwerken  oder  Rechnern  verwendet  werden. 
Im  Folgenden  wird  auf  diesen  Unterschied  genauer  eingegangen. 

Netzwerkbasiert: 


Ein  Intrusion  Detection  System  wird  in  diesem  Fall  dazu  verwendet,  ein  Netzwerk  zu 
iiberwachen[l].  Diese  Anwendung  ist  fur  einen  Angreifer  unsichtbar,  da  das  System  ledig- 
lich  die  anfallenden  Daten  abhoren  muss.  Man  spricht  deshalb  auch  davon,  dass  netzwerk- 
basierte  ID  im  ’Stealth-Modus’  operieren.  Trotz  ihrer  Aufgabe  den  gesamten  Netzwerk- 
verkehr  zu  iiberwachen,  besteht  auch  hier  die  Moglichkeit,  die  Verfahren  einer  zentralen 
Kontrolleinheit  unterstellen  zu  konnen.  Ublicherweise  versucht  man  die  Auditdaten,  falls 
moglich,  an  einem  Engpass  wie  einem  Router,  Gateway  etc.  abzugreifen  und  der  Priifung 
zu  unterziehen.  Da  gerade  in  einem  Netzwerk  eine  Vielzahl  verschiedener  Vorgange  und 
Zustande  auftreten,  nicht  zuletzt  weil  mehrere  Systeme  das  Netzwerk  benutzen,  bietet  sich 
Anomaly  Detection  weniger  an  und  man  setzt  statt  dessen  fast  immer  auf  Signature  De¬ 
tection.  Das  zieht  natiirlich  nach  sich,  dass  bei  der  Erkennung  neuer  Angriffe  unweigerlich 
Probleme  auftreten.  Das  erfordert  das  standige  Aktualisieren  der  Signature-Datenbanken 
iiber  das  Netz.  Auch  diese  konnen  wahrend  eines  Angriffs  in  das  Netzwerk  in  Mitleiden- 
schaft  gezogen  werden.  Konflikte  gibt  es  derzeit  auch  mit  kryptographisch  geschiitzten 
Verbindungen,  da  die  aktuellen  Daten  nur  in  Klartextform  mit  den  vorliegenden  Daten 
der  Signaturdatenbank  verglichen  werden  konnen.  IDS  schauen  hierbei  nicht  nur  in  die 
Protokollkopfe,  sondern  auch  in  die  Nutzdaten.  Da  dies  bei  verschliisselten  Verbindungen 
nicht  moglich  ist,  kann  das  Intrusion  Detection  System  die  Daten  nicht  iiberwachen.  Es 
sei  darauf  hingewiesen,  dass  kryptographisch  geschiitzte  Verbindungen  auch  weniger  an- 
fallig  fur  Angriffe  sind,  da  sie  durch  die  Verschliisselung  selbst  fur  einen  hoheren  Grad  an 
Sicherheit  sorgen.  Die  verschliisselten  Daten  konnen  normalerweise  nur  vom  Sender  und 
Empfanger  genutzt  werden.  Dadurch  wird  dieses  Problem  eher  nebensachlich.  Nur  bei  in- 
ternen  Bedrohungen  kann  diese  Situation  zu  Gefahr  werden.  Man  kann  auch  nicht  davon 
ausgehen,  hier  generelle  Losungen  zu  finden,  da  die  Verschliisselung  ja  darauf  ausgelegt 
ist,  dass  sie  niemand  fremdes  entziffern  kann,  auch  nicht  das  ID  System. 


Rechnerbasiert : 


Im  Gegensatz  zum  netzwerkbasierten  Intrusion  Detection  System  was  den  Verkehr  ver¬ 
schiedener  Rechner  kontrolliert,  beschaftigt  sich  hier  das  ID  System  mit  dem  Priifen  der 
Auditdaten  eines  einzelnen  Systems,  Teilsystems  oder  Users[l].  Die  Durchsuchung  lauft 
im  Wesentlichen  in  den  sicherheitsrelevanten  Protokolldateien  des  Rechners  ab.  Beispiels- 
weise  versucht  man  Eindringlinge  in  Kernel  Logfiles,  Router  Logs,  Firewall  Logs  oder 
Logfiles  von  Anwendungsprogrammen  aufzudecken.  Die  Integritat  dieser  und  ahnlicher 
systemrelevanter  Daten  erhalten  hier  die  hochste  Prioritat. 


156 


Intrusion  Detection  in  mohilen  Netzwerken 


7.3.2  Online  und  Offline  Modus 


Hier  wird  unterschieden,  ob  das  IDS  permanent  oder  sporadisch  auf  die  zu  priifenden 
Daten  angewendet  wird. 

Online: 

Ein  ID  System  lauft  online,  wenn  eine  permanente  Uberwachung  des  aktuellen  Verkehrs 
vollzogen  wird[l].  Hierbei  unterscheidet  man  zwischen  zwei  Arten  der  Online-Uberwachung. 
Die  erste  ist  die  Kontinuierliche.  Das  heifit,  dass  die  produzierten  Auditdaten  unmittelbar 
der  Prfifung  auf  Angriffe  oder  Anomalien  unterzogen  werden,  ohne  vorher  zwischenge- 
speichert  zu  werden.  Die  zweite  Art  lauft  gestapelt  ab.  Hierbei  werden  innerhalb  kurzer 
Perioden  die  anfallenden  Auditdaten  zwischengespeichert  und  nach  Ablauf  dieser  Peri- 
oden  gesammelt  der  Prufung  unterzogen.  Die  Periodendauer  ist  dabei  maximal  einige 
Sekunden  lang. 

Offline: 

Hier  geht  es  darum  die  Logfiles  und  Protokolle  des  Systems  oder  eines  Users  jeweils  nach 
einer  langeren  Arbeitsphase,  beispielsweise  einmal  pro  Tag,  auf  Eintrage  zu  untersuchen, 
die  einem  Eingriff  in  das  System  entsprechen  konnten[l].  Nachteil  davon  ist,  dass  man  nicht 
die  Moglichkeit  hat  zu  reagieren  und  Schadensbegrenzung  zu  betreiben.  Es  ermoglicht 
aber  gleichzeitig,  dass  die  Logfiles  gegebenenfalls  mehrfach  durchsucht  werden  konnen, 
um  komplexere  und  verteiltere  Angriffe  lokalisieren  zu  konnen. 


7.3.3  Intrusion  Response 


Es  handelt  sich  bei  Intrusion  Response  um  die  Mafinahmen  des  Systems,  die  unternommen 
werden  konnen,  wenn  ein  Angriff  oder  eine  Anomalie  erkannt  worden  ist.  Problematisch  ist 
dabei,  dass  Anomalien  moglicherweise  auch  neue  normale  Aktivitaten  sein  konnen,  da  es 
im  Bereich  von  Anomaly  Detection  zu  haufigen  Fehlalarmen  kommen  kann.  Diesbezuglich 
sind  die  Studien  noch  sehr  rar  und  erlauben  derzeit  noch  keine  akzeptable  Fehlalarmbe- 
handlung  bzw.  -vermeidung.  Im  Folgenden  wird  auf  die  Maflnahmen  eingegangen  die  das 
Intrusion  Detection  System  bei  einem  Eindringen  in  das  System  ergreifen  konnte[l]. 

Passiv: 

Ein  passives  ID  System  wird  bei  Alarm  den  Administrator  verstandigen,  und  ihm  bei 
Bedarf  die  Informationen  zukommen  lassen,  die  das  System  fiber  den  Angriff  in  Erfahrung 
bringen  konnte.  Mafinahmen  um  gegen  den  Angriff  vorzugehen  werden  nicht  getroffen. 
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Aktiv: 

Mafinahmen  bezuglich  des  angegriffenen  Systems: 

In  diesem  Fall  wird  versucht,  iiber  das  eigene  System  die  Kontrolle  zuriick  zu  gewinnen. 
Im  Allgemeinen  ist  man  bestrebt  die  Auswirkungen  des  Angriffs  zu  vermeiden  oder  zumin- 
dest  so  gering  wie  moglich  zu  halten.  Hierzu  ubliche  Aktionen  sind  die  Unterbrechung  der 
Verbindung,  beispielsweise  durch  das  senden  von  TCP  Reset  Paketen,  die  Sperrung  von 
kompromittierten  Benutzerkonten,  die  moglicherweise  infiltriert  wurden  um  sich  von  dort 
aus  Administratorrechte  zu  verschaffen,  das  Beenden  schadlicher  Prozesse,.die  eventuell 
Wiirmer  oder  auch  Trojaner  zugehorig  sind,  und  das  Aktivieren  einer  hoheren  Sicherheits- 
stufe,  was  neben  anderen  Mafinahmen  durch  eine  Rekonfiguration  der  Firewalls  geschehen 
kann. 

Mafinahmen  bezuglich  des  angreifenden  Systems: 

Hierbei  wird  versucht,  in  die  Operationsplattform  des  Angreifers  einzudringen  und  diese 
unschadlich  zu  machen  und  moglicherweise  entwendete  Daten  zu  entfernen.  Diese  Vor- 
gehensweise  ist  rechtlich  problematisch  und  wird  deshalb  nicht  von  Unternehmen  und 
privaten  Netzwerkbetreibern  angewandt.  Sie  findet  daher  nur  Verwendung  beim  Militar, 
beim  Bundesnachrichtendienst,  bei  der  Polizei  oder  anderen  Einrichtungen  des  Bundes. 


7.3.4  Umgang  mit  Priifdaten 

Hauptunterscheidungsmerkmal  sind  beim  Umgang  mit  den  Priifdaten  die  Aspekte  der 
Zentralisierung  und  Dezentralisierung. 

Moglichkeiten  der  Datensammlung: 

Auditdaten  konnen  an  zwei  verschiedenen  Stellen  gesammelten  werden  [1],  Sie  konnen 
von  einem  einzelnen  System,  Teilsystem  oder  User  gesammelt  und  kontrolliert  werden, 
oder  an  einem  Router,  Gateway  oder  einer  anderer  zentralen  Einheit  abgegriffen  werden, 
womit  mehrere  Systeme  miteinander  verbunden  werden  und  woriiber  die  Kommunikation 
gebundelt  wird,  so  dass  es  nicht  umgangen  werden  kann. 

Moglichkeiten  der  Datenprufung: 

Ahnlich  der  Datensammlung  kann  auch  die  Datenprufung  in  zwei  Arten  unterteilt  werden. 
Die  Auditdaten  konnen  einmal  auf  dem  System  gepriift  werden,  auf  dem  sie  gesammelt 
werden,  oder  man  verteilt  diese  Priifdaten  auf  mehrere  Intrusion  Detection  Systeme,  die 
miteinander  kooperieren[l].  So  kann  man  weiterhin  eine  gute  Performance  des  eigentlichen 
Systems  gewahrleisten,  da  die  Priifung  selbst  dieses  System  nicht  belastet.  Moglich  ist 
auch,  dass  man  die  Ergebnisse  bei  dezentralisierter  Datenprufung  miteinander  abgleicht, 
also  beispielsweise  die  anderen  Systeme  danach  fragt,  ob  sie  dieselbe  Anomalie  entdeckt 
haben,  wie  das  eigene  System. 
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7.3.5  Weitere  Aspekte 


Hierbei  handelt  es  sich  um  bisher  noch  nicht  beachtete  Eigenschaften.  Es  wird  auf  die 
Interoperabilitat  eingegangen  und  eine  Bewertung  des  Sicherheitsstandes  versucht. 

Interoperabilitat: 

Einige  Intrusion  Detection  Systeme  sind  in  der  Lage  mit  anderen  Intrusion  Detection 
Systemen  zu  kooperieren,  auch  wenn  moglicherweise  zwei  verschiedene  Methoden  der  ID 
angewandt  werden[l].  Eine  giinstige  Variante  ware  beispielsweise,  ein  Anomaly  Detection 
System  laufen  zu  lassen,  was  bei  Aufdeckung  einer  Anomalie  die  Auditdaten  an  ein  Si¬ 
gnature  Detection  System  weiterleitet.  So  konnen  sowohl  bereits  bekannte  Angriffe  also 
auch  unbekannte  Angriffe  detektiert  werden. 

Sicherheit: 

Eine  akzeptable  Leistung  beziiglich  der  Sicherheit  gewahrleisten  ID  Systeme  seit  hochstens 
5  Jahren,  davor  waren  die  Systeme  noch  in  Versuchsstadien  oder  basierten  auf  unzurei- 
chenden  Analysen  und  Studien. 


7.*3.6  Trends  und  Ziele 


Es  soil  kurz  dargelegt  werden,  inwiefern  welche  Aspekte  der  in  diesem  Kapitel  darge- 
stellten  Einsatzmoglichkeiten  in  der  naheren  Zukunft  eine  groBere  Rolle  spielen  werden. 
Man  wird  mehr  und  mehr  von  einem  passiven  Intrusion  Response  System  auf  aktive  Sys¬ 
teme  iibergehen.  Der  Vollzug  dieses  Prozesses  ist  zum  gegenwartigen  Zeitpunkt  bereits 
gut  fortgeschritten[l].  Wichtig  ist  dabei,  dass  eine  sofortige  Reaktion  erfolgen  soil,  um 
den  Angriff  moglichst  friihzeitig  bekampfen  und  Schaden  vielleicht  komplett  vermeiden 
zu  konnen.  Welcher  Prozess  hingegen  erst  durch  die  drahtlosen  Netzwerke  verstarkt  an- 
geregt  wurde,  ist  der  Trend  zu  dezentralisierten  System  beziiglich  der  Datenpriifung  und 
-sammlung[5].  Hier  befinden  wir  uns  derzeit  im  Anfangsstadium.  Ein  eindeutiger  und  auch 
zu  erwartender  Trend  ist  im  Bereich  kooperativer  ID  Systeme  zu  erkennen[l].  Fast  jedes 
moderne  Intrusion  Detection  System  bietet  die  Moglichkeit  zur  Interoperabilitat.  Auch 
das  allgemeine  Interesse  im  Bereich  der  zweiten  Verteidigungslinie  gegen  Angriffe  steigt 
und  wird  vermehrt  eingesetzt[5].  Schliefilich  ist  es  unumgangliches  Ziel,  Intrusion  Detec¬ 
tion  Systeme  standig  zu  verbessern.  Insbesondere  zielt  man  darauf  ab,  dass  einerseits  die 
Angriffsmuster  und  Modelle  des  normalen  Verhaltens  verfeinert  und  verbessert  werden, 
und  andererseits,  die  auftretenden  Fehlalarme  zu  minimieren  und  an  den  betreffenden 
Analysen  zu  forschen. 
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7.4  Probleme  und  Losungen  in  drahtloser  Umgebung 


Nach  einer  Erlauterung  der  veranderten  Situation  durch  drahtlose  Netzwerke  geht  es  in 
diesem  Kapitel  um  spezielle  neue  Herausforderungen,  die  mit  der  mobilen  Umgebung 
entstehen.  Der  wichtigste  Teil  hierbei  sind  die  moglichen  Losungsansatze  fur  dabei  ent- 
standene  Probleme  sowohl  im  Infrastruktur-Netzwerk  als  auch  in  Ad  Hoc-Netzwerk. 


7.4.1  Grundsatzliche  Probleme 


Das  offene  Medium: 

Da  elektromagnetische  Wellen  prinzipbedingt  sich  in  jede  Richtung  ausbreiten,  entsteht 
eine  deutlich  hohere  Empfanglichkeit  fur  Angriffe.  Es  wird  moglich  ohne  direkten  Kon- 
takt,  also  ohne  physikalischen  Zugriff  auf  Netzwerkkabel,  optische  Fasern  usw.,  sich  in  das 
Netzwerk  einzuklinken.  Auf  alien  Schichten  des  ISO/OSI-Modells  (Layer),  auf  jedes  Mobi¬ 
le  Node  (MN)  und  von  jedem  MN  kann  dadurch  ein  Angriff  erfolgen[5].  Ein  Angreifer  kann 
mit  geringerem  Aufwand  in  eine  internere  Ebene  vordringen  und  somit  erheblichen  Scha- 
den  anrichten.  Er  kann  den  Betroffenen  auch  passiv  schadigen,  indem  er  unbemerkt  das 
Netz  abhort.  Die  meisten  Intrusion  Detection  Systeme  brauchen  statische  Umgebungen. 
Daher  kann  es  bei  drahtloser  und  sich  standig  andernder  Umgebung  notwendig  werden, 
ein  neues  Konzept  fur  die  Intrusion  Detection  in  dynamischer  Umgebung  zu  erarbeiten 
und  anzuwenden. 

Anfalligkeit  der  Software: 

Um  solche  Angriffe  durchzufuhren  werden  Locher  und  ungewollt  kooperatives  Verhalten 
von  sicherheitsrelevanten  Dateien  und  Protokollen  ausgenutzt.  Besonders  MAC  Protokolle 
sind  sehr  anfallig  fur  Denial  of  Service  Attacken[6],  da  nur  simuliert  werden  muss,  dass 
bestimmte  Verbindungen  bereits  in  Benutzung  sind,  und  somit  nicht  fur  den  angeforderten 
Service  zur  Verfiigung  stehen. 

Weitere  Gefahren: 

Ferner  sind  auch  statische  Netzwerke  durch  unzureichend  geschiitzte  MNs  gefahrdet.  Mog- 
licherweise  konnte  ein  Wurm  in  ein  MN  gelangen  was  sich  ungeschiitzt  im  Internet  aufhalt. 
Wenn  dieses  MN  sich  nun  in  ein  nach  aufien  gut  geschutztes  statisches  Netzwerk  einklinkt, 
beispielsweise  ein  Mitarbeiter  verbindet  sich  in  seiner  Firma  mit  dem  LAN,  so  kann  es 
zur  Infizierung  des  statischen  Netzwerkes  von  innen  heraus  kommen. 
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7.4.2  Herausforderungen 


Dezentralisierung  und  Lokalisierung: 

Die  Moglichkeit  des  Angriffs  ohne  festes  Medium  erschwert  betrachtlich  die  Lokalisierung 
des  Angreifers.  Andererseits  kann  die  schlechte  Lokalisierung  auch  zum  Vorteil  genutzt 
werden,  wenn  ein  Angreifer  ein  ganz  bestimmtes  Ziel  hat,  da  er  dieses  vorher  auch  erst 
einmal  lokalisieren  muss.  Weiterhin  gibt  es  in  mobiler  Umgebung  weniger  Verkehrskon- 
zentrationspunkte,  so  dass  die  zu  iiberpriifenden  Daten  von  uberall  her  kommen,  und 
schliefilich  auch  nur  lokal  vorliegen.  Es  stellt  sich  die  Frage,  ob  man  moglicherweise  auch 
in  dezentralisierter  und  globaler  Form  Intrusion  Detection  betreiben  kann.  Dies  erfordert 
jedoch  die  Mitarbeit  der  anderen  MNs  im  Netzwerk. 

Daten  fur  ID  Systeme: 

In  drahtloser  Umgebung  werden  neue  Anwendungen  und  Verkehrsmuster  notig.  Doch  lau- 
fende  Operationen  konnen  durch  die  zerbrechlichere  Kommunikation  leicht  unterbrochen 
werden.  Moglicherweise  kann  die  Funkreichweite  kurzzeitig  nicht  ausreichen  oder  das  Si¬ 
gnal  trifft  auf  ein  Hindernis.  Das  kann  zwei  Konflikte  zur  Folge  haben.  Wenn  die  Daten  mit 
grofierer  Verzogerung  eintreffen,  so  ist  es  fur  die  iiblicherweise  echtzeit-basierten  Intrusion 
Detection  Systeme  schwer  bzw.  nicht  moglich,  auch  in  Echtzeit  die  Daten  zu  prufen[5]. 
Noch  problematischer  wird  es,  wenn  die  Daten  unvollstandig  vorliegen,  das  heifit,  wenn 
Daten  auf  dem  Weg  unwiederbringlich  verloren  gehen.  Die  Intrusion  Detection  Methoden 
konnen  nur  auf  vollstandige  Daten  angewandt  werden,  denn  moglicherweise  fehlte  gerade 
ein  soldier  Teil,  mit  dem  man  eine  Signatur  oder  Anomalie  hatte  erkennen  k5nnen[5]. 
Da  dann  jedoch  die  Daten  des  moglichen  Angriffs  nicht  vollstandig  sind,  besteht  weniger 
Gefahr  fur  das  iiberwachte  System,  man  kann  jedoch  auch  nicht  in  Erfahrung  bringen,  ob 
man  von  jemandem  als  Ziel  auserkoren  wurde.  Es  stellt  sich  die  Frage,  welche  Algorithmen 
man  bei  unvollstandigen  Daten  anwenden  konnte. 


7.4.3  Vorgehensweise  in  Infrastruktur-Netzwerken 


In  Infrastruktur-Netzwerken  gibt  es  einige  Losungsansatze  die  im  Folgenden  genauer  skiz- 
ziert  werden. 

Probleme  und  Losungsansatze  beziiglich  der  Schichten  des  ISO/OSI-Modells: 

In  drahtloser  Umgebung  ist  es  fur  den  Angreifer  moglich  auf  alien  Schichten  zu  operieren. 
Die  MAC-Ebene  ist  hierbei  eine  besonders  anfallige  Schicht.  Um  das  Problem  zu  bekamp- 
fen,  versucht  man  sie  durch  eine  auf  Layer  3  basierte  Firewall  zu  isolieren[5].  Wenn  das 
Intrusion  Detection  System  eine  Anomalie  auf  einem  der  unteren  Layer  entdeckt,  so  weist 
das  haufig  darauf  hin,  dass  auf  einem  hoheren  Layer  ein  Eingriff  stattgefunden  hat. 
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Losungsansatz  fiir  Angriffe  auf  Infrastruktur-Netzwerke: 

Die  Idee  ist,  dass  jedes  neue  Mobile  Node,  welches  sich  ins  Netzwerk  einklinkt,  sofort 
an  einem  gemeinsamen,  globalen  Intrusion  Detection  Prozess  teilnimmt[5].  Nachdem  es 
in  den  Prozess  integriert  wurde,  fangt  das  lokale  ID  System  an,  Wissen  iiber  die  Umge- 
bung  zu  sammeln,  um  mit  anderen  Intrusion  Detection  Sensoren  kooperieren  zu  konnen. 
Entscheidend  ist  dabei  die  umgehende  Aktualisierung  der  Signaturdatenbank.  Bei  jedem 
Neuaufbau  einer  Verbindung  (reconnect)  ist  dieser  Vorgang  zu  wiederholen.  Wichtig  ist  bei 
dem  Integrationsprozess,  dass  er  in  der  Lage  sein  sollte  automatisch  ablaufen  zu  konnen, 
da  bei  manuellem  Einstellen  damit  zu  rechnen  ist,  dass  es  vergessen  wird  oder  fehlerbe- 
haftet  sein  kann,  und  nicht  zuletzt  zeitintensiv  und  lastig  fiir  den  Anwender  ist [5].  Im 
Allgemeinen  werden  die  speziellen  Vorgehensweisen  von  dem  ungelernten  Benutzer  soweit 
wie  moglich  versteckt,  da  solch  eine  fehlerbehaftete  Konfiguration  das  gesamte  Netzwerk 
in  Gefahr  bringen  kann.  Gleichzeitig  nutzt  man  die  schlechte  Lokalisierbarkeit  von  mo- 
bilen  Endgeraten  zum  eigenen  Vorteil  aus,  um  selbst  einem  speziell  auf  sich  gerichteten 
Angriff  entgehen  zu  konnen[6].  Durch  das  automatische  Update  und  sofortige  Integration 
neuer  Mobile  Nodes  kann  eine  optimale  Nutzung  garantiert  werden,  so  dass  schlieBlich 
Intrusion  Detection  in  dynamischer  Umgebung  moglich  wird. 


7.4.4  Vorgehensweise  in  Ad  Hoc-Netzwerken 

In  Ad  Hoc-Netzwerken  ist  es  noch  etwas  komplizierter  die  Sicherheit  zu  waren.  Mogli- 
*  cherweise  konnten  diese  Losungsansatze  dazu  beitragen,  die  auftretenden  Probleme  zu 
beseitigen. 

Schichtiibergreifende  Intrusion  Detection: 

Auch  bei  Ad  Hoc-Netzwerken  konnen  die  Probleme  in  alien  Schichten  auftreten.  Jede 
Schicht  ist  in  mobiler  Umgebung  einfacher  angreifbar.  Die  Sicherheit  auf  Mobile  Nodes  ist 
derjenigen  im  drahtgebundenen  Netz  noch  deutlich  unterlegen.  Deshalb  sollte  ein  Intrusion 
Detection  System  auf  verschiedenen  Layern  arbeiten  konnen.  Bei  einer  Anomalie  in  einem 
der  Layer  wird  dann  den  ID  Sensoren,  die  auf  den  anderen  Layern  arbeiten,  eine  Warnung 
geschickt[6]. 

Losungsansatz  fur  Angriffe  auf  Ad  Hoc-Netzwerke: 

Die  Dezentralisierung  bedeutet  fiir  jedes  Mobile  Node  einen  hohen  Grad  an  Verwundbar- 
keit.  In  Ad  Hoc  Netzwerken  kommt  hinzu,  dass  durch  die  Fremdartigkeit  der  Kommuni- 
kationspartner  die  Sicherheit  nicht  mehr  gewahrleistet  werden  kann.  Deshalb  sollte  jedes 
MN  erstmal  grundsatzlich  fiir  sich  selbst  Intrusion  Detection  betreiben  konnen  [6].  Nun 
geht  man  einen  Schritt  weiter.  Wenn  die  anderen  MNs  in  der  Lage  sind  mit  dem  eigenen 
MN  Intrusion  Detection  zu  betreiben,  so  sollte  man  zusatzlich  zum  eigenen  Ergebnis  die 
anderen  MNs  zu  Rate  ziehen[6].  Jedoch  ist  das  nur  als  Erganzung  zu  betrachten.  Eine 
mogliche  Ausfiihrung  sieht  vor,  in  jedem  MN  einen  Intrusion  Detection  System  Agent 
installiert  zu  haben,  und  zunachst  die  Sammlung  und  Priifung  der  Daten  lokal,  also  nur 
fiir  das  eigene  Mobile  Node,  durchzufiihren.  Weiterhin  geht  man  so  vor,  dass  man  bei 
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einer  auftretenden  Anomalie  mit  den  Nachbarn  kommuniziert,  und  eine  globale  Prtifung 
der  Daten  anordnet[6].  Die  zugesendeten  Daten  sollten  dabei  nicht  verwendet  werden,  da 
eine  absichtliche  Falschung  oder  bosartiger  Code  enthalten  sein  kann.  Die  Kommunika- 
tion  zwischen  sich  und  den  Nachbarn  wird  durch  eine  so  genannte  ’secure  communica¬ 
tion  engine’  gefiihrt ,  die  den  Datentransfer  iiberwacht  und  versucht  mehr  Sicherheit  zu 
gewahrleisten[6].  Sie  ist  Bestandteil  eines  jeden  IDS  Agents.  Da  bei  der  Kommunikati- 
on  mit  naheren  Nachbarn  weniger  fehlerhafte  Datenpakete  entstehen,  da  die  Entfernung 
geringer  ist  und  durchschnittlich  weniger  Storungen  auftreten,  erhalten  ihre  Ergebnisse 
eine  hohere  Prioritat[6].  Wenn  eine  ausreichend  eindeutige  Bewertung  durch  die  globale 
Untersuchung  getatigt  wurde,  und  deshalb  davon  ausgegangen  werden  kann,  dass  eine  An¬ 
omalie  tatsachlich  vorliegt,  kann  eine  globale  Reaktion  auf  diesen  Eingriff  vorgenommen 
werden.  Diese  kann  von  jedem  beliebigem  Mobile  Node  getatigt  werden,  nicht  zwangsweise 
durch  das  eigene.  Die  Mafinahme  ist  nun  abhangig  von  der  Art  des  Angriffs,  der  Art  der 
Netzwerkprotokolle  und  wie  hoch  das  Vertrauen  in  das  Ergebnis  ist,  also  wenn  moglichst 
alle  die  Anomalie  bestatigt  haben[6].  Die  Intrusion  Response  sieht  vor,  die  Kommuni- 
kation  zwischen  den  Teilnehmern  neu  zu  initialisieren,  in  dem  beispielsweise  die  Login- 
Keys  neu  angefordert  werden[6].  Konnte  der  Eindringling  identifiziert  werden,  wird  eine 
Reorganisation  der  Netzwerkstruktur  unter  Ausschluss  unerwiinschter  MNs  eingeleitet. 
Problematisch  ist  aufierdem  die  Datenkontrolle,  da  keine  Router,  Gateways  oder  andere 
Verkehrsknotenpunkte  vorhanden  sind,  an  denen  man  die  zu  priifenden  Daten  auslesen 
kann.  In  einem  gemeinsamen  Medium  ist  das  zwar  nicht  unbedingt  erforderlich,  da  alle 
MNs  alle  Daten  empfangen  konnen,  aber  stattdessen  entsteht  in  einem  infrastrukturlosen 
Netzwerk  das  Problem  der  so  genannten  ’hidden  stations’,  wobei  die  Erkennung  eines  be- 
legten  Kanals  nicht  in  alien  Situationen  zuverlassig  funktioniert.  Hier  kurz  eine  Erklarung 
des  Problems.  Eine  Station  kommuniziert  mit  einer  zweiten,  mit  der  eine  weitere  Station 
nun  auch  kommunizieren  mochte.  Wenn  nun  diese  dritte  Station  die  erste  nicht  erkennen 
kann,  weil  diese  beispielsweise  aufierhalb  der  Reichweite  liegt,  geht  sie  davon  aus,  der  Ka- 
nal  ware  frei,  und  sendet  die  Datenpakete.  Diese  gehen  jedoch  verloren,  da  der  Kanal  in 
Wirklichkeit  belegt  ist.  Dies  kann  natiirlich  dazu  fuhren,  dass  die  Daten  nur  unvollstandig 
vorliegen.  Hier  tritt  wieder  das  Problem  auf,  welche  Algorithmen  man  fur  unvollstandige 
Daten  verwenden  sollte. 


7.5  Fazit 


Diese  Ausarbeitung  diente  im  Rahmen  eines  Seminars  dazu  dem  Interessierten  naher  zu 
bringen,  worum  es  in  der  Intrusion  Detection  geht.  Es  wurden  die  Methoden  der  Intrusion 
Detection  angerissen  und  auf  die  vielfaltigen  Varianten  des  Einsatzes  von  ID  Systemen  ein- 
gegangen.  Entscheidend  war  besonders  die  Darlegung  der  Umsetzung  von  Intrusion  Detec¬ 
tion  in  die  drahtlose  Umgebung  und  welche  Ansatze  derzeit  zu  deren  Verwirklichung  exis- 
tieren.  Es  wurde  herausgestellt,  dass  ohne  einige  Anderungen  vorzunehmen  man  Intrusion 
Detection  also  nicht  von  drahtgebundener  Umgebung  in  drahtlose  Umgebungen  iiberneh- 
men  kann.  Hierbei  wurde  ein  deutlicher  Unterschied  zwischen  Infrastruktur-Netzwerken 
und  Ad  Hoc-Netzwerken  gemacht.  Beide  Losungen  fordern  die  Mitarbeit  der  Kommu- 
nikationspartner  des  Netzwerkes,  doch  wahrend  man  bei  einem  Infrastrukturnetzwerk 
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eine  noch  recht  einfache  und  sichere  Losung  hatte,  ist  die  Losung  bei  Ad  Hoc-Netzwerken 
schwieriger  zu  realisieren  und  bietet  einen  nicht  ganz  so  hohen  Grad  an  Sicherheit.  Zusam- 
menfassend  kann  man  sagen,  dass  fiir  beides  eine  realistische  Moglichkeit  der  Umsetzung 
existiert.  Bei  einem  zunehmend  bedrohlichen  Angriffsszenario  kann  es  sowohl  fiir  mobi¬ 
le,  als  auch  fiir  stationare  Systeme  sinnvoll  oder  gar  notwendig  sein,  Intrusion  Detection 
Systeme  einzusetzen. 
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Kapitel  8 

Software  Environments  for  Mobile 
Devices 

Michael  Bohm 


Der  Markt  fur  mobile  Gerate  hat  in  den  letzten  Jahren  immens  an  Bedeutung  gewonnen. 
Wegen  der  begrenzten  Resourcen  derartiger  Systeme  werden  auch  besondere  Anforderun- 
gen  an  entsprechende  Betriebssysteme  gestellt.  Die  gangisten  Betriebssysteme  im  Bereich 
*  von  mobilen  Systemen  sind  Symbian,  die  Microsoft  Familie  und  natiirlich  Linux.  Symbian 
ist  im  Bereich  von  Handys  am  weitesten  verbreitet  und  bietet  den  grofien  Vorteil,  dass  alle 
Partner  des  Konsortiums  den  Sourcecode  abandern  und  an  ihre  Bedurfnisse  anpassen  kon- 
nen.  Microsoft  macht  die  Hersteller  zu  reinen  Hardwarelieferanten,  hat  aber  den  Vorteil, 
dass  durch  die  weite  Verbreitung  von  Microsoft  Betriebssystemen  auf  PCs  das  Abgleichen 
von  Daten  mit  dem  Pc  erleichtert  wird.  Letztendlich  bleibt  noch  Linux.  Linux  bietet  den 
Vorteil,  dass  es  sehr  Zuverlassig  und  stabil  arbeitet.  Leider  ist  es  im  Bereich  von  handys 
noch  immer  ein  Nischenprodukt.  Auch  an  die  Programmierumgebung  fur  mobile  Gerate 
werden  spezielle  Anforderungen  gestellt.  Auch  hier  spielen  die  begrenzten  Resourcen  eine 
grofle  Rolle.  Java  stellt  dafur  J2ME  zur  verfugung,  eine  eingeschrankte  Version  fur  derar- 
tige  Systeme.  Da  das  API,  das  mit  dieser  Konfiguration  ausgeliefert  wird,  dem  Entwickler 
nur  einige  Grundfunktionalitaten  zur  Verfugung  stellt,  bedarf  es  einer  Erweiterung  die¬ 
ses  API’s  mittels  eines  zusatzlichen  Profils.  Das  Profit  wird  in  diesem  Einsatzgebiete  mit 
“ Mobile  Information  Device  Profile11  (MIDP)  bezeichnet. 
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8.1  Einleitung 


Diese  Arbeit  beschaftigt  sich  mit  den  gangigsten  Betriebssystemen  fur  mobile  Systeme  und 
soil  einen  kurzen  Einblick  in  die  Programmierplattform  J2ME  ermoglichen.  Zunachst  soli 
auf  allgemeine  Anforderungen  fur  derartige  Betriebssysteme  eingegangen  werden,  bevor 
die  gangigsten  Betriebssysteme  im  einzelnen  naher  betrachtet  werden.  Nachdem  Symbian 
in  Europa  klar  den  Markt  beherrscht,  soil  an  diesem  Beispiel  der  Aufbau  eines  Betriebssys- 
tems  fur  mobile  Systeme  erlautert  werden.  Danach  werden  die  hier  vorgestellten  Systeme 
anhand  bestimmter  Kriterien  bewertet.  Zuletzt  beschaftigt  sich  diese  Arbeit  noch  mit 
J2ME  und  zeigt  auf,  was  fur  die  Zukunft  auf  diesem  Markt  noch  zu  erwarten  ist. 

Was  sind  mobile  Systeme?  Mobile  Systeme  sind  Rechensysteme,  die  mitgefuhrt  werden 
konnen  (Smartphones,  Handys,  Palmtops,  etc.),  oder  die  sich  selbst  bewegen  (Auto,  Fug- 
zeug,  etc.).  Letztere  spielen  aber  fur  diese  Arbeit  eine  untergeordnete  Rolle.  Obwohl  die 
Grenzen  zwischen  Betriebssystemen  fur  mobile  und  stationare  Systeme  immer  mehr  ver- 
schwimmen,  lassen  sie  sich  in  manchen  Punkten  klar  voneinander  abgrenzen. 

Was  ist  ein  Betriebssystem?  Ein  Betriebssystem  ist  die  Organisations-  beziehungsweise 
Verwaltungseinheit  innerhalb  von  Rechensystemen.  Die  primare  Aufgabe  ist  die  Verwal- 
tung  der  zur  Verfiigung  stehenden  Betriebsmittel.  Fur  den  Benutzer  erheblich  ist  allerdings 
der  Zugang  zum  System  uber  eine  virtuelle  Maschine,  die  er  leichter  handhaben  kann  als 
die  Maschine  selbst. 

Was  ist  ein  embedded  System?  Betriebssysteme,  die  keinen  direkten  Zugriff  auf  sich  selbst 
erlauben,  nennt  man  embedded  Systems  (engl.:  eingelassen,  verborgen).  Sie  kommen  im 
Bereich  der  Echtzeit-Systeme  besonders  zum  Tragen,  auch  wenn  das  wiederum  nur  einen 
Teil  darstellt.  Weit  iiber  90%  aller  Systeme  werden  auf  embedded  Systems  zuriickgefuhrt, 
was  auch  die  Grundlage  fur  diesen  hart  umkampften  Markt  ist.  Es  diirfte  schnell  einseh- 
bar  sein,  dass  der  Markt  fur  gangige  Betriebssysteme  in  diesem  Zusammenhang  nur  ein 
“kleiner  Fisch“  ist.  [9] 

Man  kann  schon  an  dieser  Stelle  einige  Probleme  erkennen,  die  sich  im  Zusammenhang 
mit  mobilen  Systemen  und  deren  Eigenschaften  ergeben.  Es  ist  verstandlich,  dass  man 
an  Betriebssysteme  fur  mobile  Systeme,  die  keinen  Einfluss  vom  Endverbraucher  erlau¬ 
ben  und  eingebettet  in  ihre  Umgebung  ohne  Reboot  oder  dauerhafte  Stromversorgung 
auskommen  miissen,  ganz  besondere  Anforderungen  stellt.  Die  Tatsache,  dass  sich  mobi¬ 
le  Systeme  immer  groBerer  Beliebtheit  erfreuen,  macht  deutlich,  dass  in  dieser  Richtung 
noch  einiges  geschehen  muss  und  wird. 


8.2  Anforderungen  an  Betriebssysteme  fur  mobile  Sys¬ 
teme 

Mobile  Systeme  jeglicher  Art  verdanken  ihren  hohen  Nutzwert  ihrer  Mobilitat.  Seien  es 
mobile  Telefone,  PDAs  oder  auch  solche  mobile  Systeme  in  modernen  Autos,  sie  alle 
wiirden  ihren  Sinn  verlieren,  wenn  sie  stationar  gebunden  waren.  Um  Anforderungen  fest- 
halten  zu  konnen,  muss  man  im  Allgemeinen  daher,  gebunden  an  die  Fragen  “Wie  hoch  soil 
die  Mobiliat  sein?“  und  “In  was  fur  einem  Endprodukt  soli  das  Betriebssystem  eingesetzt 
werden?“,  grundlegend  zwischen  folgenden  Gesichtspunkten  unterscheiden: 
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•  datenspezifisch 

Wie  wird  die  Speicherung  realisiert? 

Wie  hoch  darf/soll  die  externe/interne  Kommunikation  sein? 

Welche  Transfergeschwindigkeiten  sind  erwiinscht? 

•  versorgungsspezifisch 

Wie  wird  die  Stromversorgung  geregelt? 

Wie  lange  muss  das  System  ohne  Zugang  zu  einem  festen 
Stromnetz  auskommen  konnen? 

Wie  sind  Updates  oder  Anwendungen  Dritter  zuganglich? 

•  sicherheitsspezifisch 

Welche  Angriffspunkte  birgt  die  Mobilitat? 

Inwieweit  schrankt  eine  hohere  Sicherheit  andere  Gebiete  ein? 

Wie  schiitzt  sich  das  System  gegeniiber  Ausfallen  oder  Eingriffen  dutch 
Anwendungen  eines  Drittherstellers? 

•  produktspezifisch 

1st  minimaler  Platz  erforderlich? 

Sind  besondere  Anwendungen  verlangt/ausgeschlossen? 

Wie  kann  ich  das  Betriebssystem  erweitern,  verandern  oder  anpassen? 

Natiirlich  konnte  man  noch  einige  Fragen  erganzen,  doch  sollen  die  hier  aufgefiihrten  Fra- 
gen  fiir  diese  Arbeit  ausreichen.  Wie  in  vielen  anderen  Bereichen  auch,  sind  Uberschnei- 
dungen  der  einzelnen  Fragen  nicht  zu  vermeiden.  Mit  Hilfe  der  gestellten  Fragen  soli  nun 
versucht  werden,  die  Anforderungen  an  Betriebssysteme  fiir  mobile  Systeme  zu  erarbeiten 
und  festzuhalten.  Auch  wenn  die  einzelnen  Hersteller  verschiedene  Schwerpunkte  setzen 
und  Probleme  auf  verschiedene  Art  und  Weise  zu  losen  versuchen,  stehen  sie  doch  den 
gleichen  Problemstellungen  gegeniiber. 

8.2.1  Stabilitat  und  Ausfallsicherheit 

Ausfalle  und  fehlende  Stabilitat  sind  bei  PCs  keine  Seltenheit.  Haben  diese  Probleme  bei 
den  herkommlichen  PCs  keine  schwerwiegenden  Folgen,  ist  das  bei  enbedded  Systems  an- 
ders.  Im  Mobilfunkbereich  ergeben  sich  zwar  keine  schwerwiegenden  Folgen,  doch  wird  es 
der  Verbraucher  nicht  hinnehmen,  wenn  starke  Schwankungen  in  der  Ubertragungsqualitat 
auftreten,  oder  die  Verbindung  ofter  zusammenbricht.  In  Anbetracht  der  Einsatzgebiete 
sind  diese  Anforderungen  fiir  embedded  Systems  unabdingbar.  Will  man  schon  hier  einen 
kurzen  Vergleich  mit  gangigen  PC-Betriebssystemen  anstellen,  dann  grenzt  ein  solches 
Unterfangen  schon  fast  an  eine  unmogliche  Aufgabe.  [8] 


8.2.2  Speicherbedarf 

Der  minimale  Speicherbedarf  beziehungsweise  die  Grofie  des  Systems  ist  stark  abhangig 
vom  Einsatzgebiet.  Muss  man  beispielsweise  ein  Betriebssystem  fiir  ein  Mobiltelefon  ent- 
werfen,  dann  ist  zum  einen  nicht  viel  Platz  fiir  ein  umfangreiches  System  und  zum  anderen 
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sind  die  Kundenwiinsche  stark  “eingeschrankt11.  Neben  Telefonie  sollen  bestimmte  Appli- 
kationen  im  Umfang  des  Angebotes  zur  Verfiigung  stehen,  aber  die  Bootzeit  (Starten  des 
Betriebssystems)  darf  sich  dabei,  abgesehen  einer  gewissen  Toleranz,  nicht  verandern.  Ent- 
wirft  man  allerdings  ein  Betriebssystem  im  Bereich  einer  Auto-  oder  Jetsteuerung,  dann  ist 
gegebenenfalls  der  Platz  Nebensache  und  die  Ausfallsicherheit  bzw.  die  Sicherheitssubrou- 
tinen  stehen  im  wesentlichen  Vordergrund.  Die  Folge  ist  klar  ersichtlich:  Spezialisierung. 

[7] 

8.2.3  Powermanagement 

Einige  mobile  Systeme  miissen  eine  lange  Zeit  (z.B.  mehrere  Tage)  ohne  Stromversorgung 
auskommen  oder  im  Falle  eines  Mobiltelefons  noch  aktiv  sein,  obwohl  das  Gerat  abgeschal- 
tet  wurde,  damit  beispielsweise  der  Benutzer  mit  einem  Alarm  an  einen  Termin  erinnert 
werden  kann.  Ein  jeweiliges  Betriebssystem  darf  dem  nicht  hinderlich  im  Weg  stehen, 
sondern  muss  mit  einer  intelligenten  Ressourcenverteilung  und  -nutzung  das  Management 
verbessern  und  dafiir  sorgen,  dass  es  geniigsam  mit  vorhandenen  Betriebsmitteln  umgeht. 

8.2.4  Echtzeiteigenschaften 

Es  ware  wiinschenswert,  wenn  man  Echtzeit-Verhalten  in  manchen  Bereichen  erzielen 
konnte,  doch  sind  diese  Eigenschaften  nicht  unbedingt  notwendig.  Allerdings  ist  klar,  dass 
der  User  gewisse  Dinge  hinsichtlich  “Echtzeit"  erwartet.  Das  System  sollte  also  durchaus 
in  der  Lage  sein,  bestimmte  Aufgaben  in  bestimmten  Zeitintervallen  zu  erledigen.  So 
erwartet  man  z.B.,  dass  bei  einem  eingehenden  Anruf  die  momentane  Anwendung  unter- 
brochen  wird,  um  den  Anruf  entgegenzunehmen.  Symbian  hat  dieses  Problem  aufgegriffen 
und  mit  der  neusten  Version  Symbian  OS  V8.0  versucht  zu  losen.  Laut  Microsoft  ist  ein 
echtzeitfahiges  Betriebssystem  durchaus  realisierbar  [4] 

8.3  Die  gangigsten  Betriebssysteme  -  Uberblick 


Die  zwei  wichtigsten  Hersteller  fur  derartige  Betriebssystem  sind  Symbian  und  Micro¬ 
soft.  Beide  konkurrieren  auf  dem  Markt  um  die  Vorherrschaft.  Wobei  der  europaische 
Markt  momentan  fest  in  Handen  von  Symbian  ist.  Aber  Microsoft  befindet  sich  auf  dem 
Vormarsch.  Als  drittes  wichtiges  Betriebssystem  miissen  wir  noch  Linux  betrachten,  auch 
wenn  dieses  Betriebssystem  einige  Vorteile  bietet,  ist  es  bei  weitem  nicht  so  weit  verbreitet, 
wie  Symbian  OS  oder  die  Betriebssysteme  der  Microsoft  Familie. 


8.3.1  Symbian 

Symbian  wurde  vor  sieben  Jahren  von  Nokia  und  anderen  Branchengrofien  gegrundet,  um 
ein  Betriebssystem  fur  Smartphones  zu  entwickeln.  Das  Joint  Venture  war  dabei  hochst 
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erfolgreich,  rund  94  Prozent  aller  Smartphones,  die  etwa  im  zweiten  Quartal  in  Europa, 
dem  Nahen  Osten  und  Afrika  verkauft  worden  sind,  laufen  mit  Symbian-Software.  Mi¬ 
crosoft  blieb  mit  seinem  Handy-Betriebssystem  dagegen  in  Europa  bisher  eher  erfolglos. 
Allerdings  hatte  sich  Motorola  im  August  2002  von  Symbian  zuriickgezogen  und  war  eine 
Allianz  mit  Microsoft  eingegangen. 

Trotz  dieser  neuen  Allianz  ist  Symbian-Chef  Levin  auch  fur  die  Zukunft  optimistisch: 
Microsoft  werde  sich  am  Mobiltelefon  nicht  durchsetzen,  weil  es  die  Handyproduzenten 
zu  reinen  Hardwarelieferanten  mache  und  deshalb  die  Gewinnmoglichkeiten  reduziere. 
Symbian  dagegen  liefere  nicht,  wie  es  der  Redmonder  Konzern  praktiziere,  eine  Software 
an  die  Kunden,  mit  der  sie  ohne  Wenn  und  Aber  leben  miissten.  “Jeder  Lizenznehmer  kann 
die  Software  individuell  anpassen.  Jedes  Symbian-Handy  von  Nokia  oder  Sony-Ericsson 
ist  mit  anderen  Diensten  ausgestattet.  Trotzdem  “sprechen11  beide  Handys  miteinander", 
sagte  Levin. 

Die  Firma  Symbian  stellt  Betriebssysteme  fiir  mobile  Telefone  her.  Dabei  legt  sie  ihr 
Marktsegment  sowohl  arif  die  sogenannten  Smartphones  (Telefone  mit  PDA-Fahigkeiten) 
als  auch  auf  die  Communicators  (PDAs  mit  Telefonie).  Laut  diverser  Firmen  kann  man 
erkennen,  dass  sich  dieser  Markt  iiberschlagt  und  fast  monatlich  neue  Modelle  oder  Anwen- 
dungen  fiir  den  Endbenutzer  zuganglich  werden.  Innerhalb  dieser  rasanten  Entwicklung 
scheinen  Stabilitat  und  Ausfallsicherheit  fast  sekundar,  wenn  man  Probleme  moderner 
Handys  betrachtet.  Grundlegend  gibt  es  laut  Symbian  White  Papers  ganz  andere  Ei- 
genschaften,  die  hier  eine  primare  Rolle  spielen.  Es  sollen  nun  einige  dieser  besonderen 
Anforderungen  aufgelistet  werden. 

•  Funktionalitat 

t  Gemafi  der  rasanten  Entwicklung  muss  ein  Betriebssystem  zukunftsorientiert  ausge- 
legt  sein.  Es  darf  nicht  schon  mit  der  nachsten  Hardwareentwicklung  veraltet  sein. 
Man  unterscheidet  zwischen  Hilfsfunktionalitat  (Anwendungen  wie  Rechner,  Mu- 
sikspieler,  ein  Spiel)  und  Integritatsfunktionalitat  (z.B.  verbesserte  Datenbanken, 
intelligentere  Speicherung  von  Daten).  In  diesem  Zusammenhang  spielt  auch  die  An- 
passungsfahigkeit  eine  Rolle.  Denn  nur  das  Betriebssystem,  das  auch  die  nachste 
Generation  Mobiltelefone  unterstiitzt,  kann  sich  auch  langfristig  auf  dem  Markt  be- 
haupten. 

•  Spezielle  Hardware 

Bei  der  GroBe  des  Endprodukts  und  der  hohen  Leistungsfahigkeit  eines  dazugeho- 
rigen  Betriebssystems  miissen  spezielle  Bausteine  (CPU,  Speicher,  etc.)  integriert 
werden.  [8] 

•  Offenes  System 

Ausgelegt  als  ein  offenes  Betriebssystem,  das  sich  als  Standard  fiir  den  Mobiltelefon- 
markt  einbiirgern  sollte,  muss  sich  das  System  erweitern  und  verandern  lassen.  Auch 
das  stellt  besondere  Anforderungen  an  das  System,  da  es  in  seinen  Grundfesten  bei 
Anderungen  nicht  einfach  “auseinanderbrechen“  darf. 

•  Ausfallsicherheit  und  Stabilitat 

Der  Endbenutzer  sieht  es  als  selbstverstandlich  Software  oder  Anwendungen  fiir  sei¬ 
nen  Organizer  zu  laden.  Um  die  Integritat  des  Systems  zu  wahren,  muss  der  Be- 
triebssystemkern  stabil  und  unempfanglich  gegen  Ausfalle  sein. 
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•  Effiziente  Nutzung  der  begrenzten  Ressourcen 

Man  muss  sich  vor  Augen  fiihren,  dass  physikalische  Netze  immer  schneller  sein  wer- 
den  als  die  drahtlose  Ubertragung.  Der  Versuch  in  direkte  Konkurrenz  zu  treten 
ware  im  vornherein  zum  Scheitern  verurteilt.  Daher  muss  man  gerade  in  diesem  Be- 
reich  darauf  zuriickgreifen  was  man  hat.  Wenn  man  also  die  globale  Geschwindigkeit 
von  Ubertragungsraten  selbst  nicht  erhohen  kann,  dann  muss  dafiir  gesorgt  werden, 
dass  die  Ubertragung  selbst  effizient  und  schnell  abgewickelt  werden  kann.  Das  Sys¬ 
tem  muss  in  Echtzeit  in  der  Lage  sein  den  Nutzer  iiber  den  aktuellen  Status  zu 
informieren  und  mittels  geeigneter  Protokolle  jede  Phase  von  Erreichbarkeit  sinnvoll 
auszunutzen. 


8.3.2  Microsoft  Familie 


Microsoft  hat  selbstverstandlich  auch  in  diesem  Markt  ein  Interesse  Prasenz  zu  zeigen. 
Hauptaugenmerk  der  Firma  war  es  allerdings  besonders  flexible  und  skalierbare  Plattfor- 
men  zu  entwickeln,  weniger  sich  auf  ein  spezielles  Marktsegment  festzulegen.  Das  neuste 
Betriebssystem  von  Microsoft  ist  Windows  Mobile  2003.  Zum  Verstandnis,  was  Windows 
Mobile  2003  ist,  muss  etwas  ausgeholt  werden,  denn  Microsoft  verfolgt  eine  Produkt- 
strategie,  die  von  der  anderer  Entwickler  von  Mobilcomputer-Betriebssystemen  abweicht. 
Die  wichtigste  Konkurrenz,  Symbian  mit  SymbianOS,  bedient  nur  jeweils  einen  stark  ab- 
gegrenzten  Markt,  also  Handhelds,  beziehungsweise  Smartphones,  wahrend  Microsoft  in 
jedem  Lebensbereich  prasent  sein  will.  Microsoft  hat  daher  seit  1996  an  Windows  CE  ge- 
arbeitet,  welches  in  angepasster  Form  in  Unterhaltungselektronik,  Handhelds,  aber  auch 
Smartphones  zum  Einsatz  kommt.  Das  in  den  stiftbedienten  PDAs,  den  Pocket  PCs,  ver- 
wendete  Betriebssystem  basiert  auf  Windows  CE,  wurde  aber  um  spezielle  Anwendungen 
wie  Textverarbeitung,  Tabellenkalkulation,  Media  Player  und  anderes  erganzt,  die  bei 
anderen  Windows  CE-basierten  Produkten  in  dieser  Form  nicht  zu  finden  sind.  Tatsach- 
lich  basierte  das  Betriebssystem  weiterhin  auf  Windows  CE  3.0,  bekam  aber  zusatzli- 
che  Anwendungen  zur  Seite.  Irritierend  ist,  dass  Microsoft  seitdem  auch  von  “Windows 
powered“-Geraten  spricht,  obwohl  sich  die  Kompatibilitat  mit  Desktop- Windows  auf  den 
Datenaustausch  beschrankt.  Anwendungen  vom  Windows-PC  laufen  dagegen  nicht  auf 
dem  PDA.  Das  am  23.  Juni  2003  vorgestellte,  neueste  Betriebssystem  heifit  jetzt  “Mo¬ 
bile  Windows  2003“  und  basiert  nicht  mehr  auf  den  Betriebssystemkern  “Windows  CE“, 
sondern  auf  den  Nachfolger  “Windows  CE.NET“.  Die  meisten  Anderungen  sind  unter  der 
Oberflache  zu  finden  und  betreffen  die  drahtlose  Kommunikation.  Als  Pocket  PC  2002 
auf  den  Markt  kam,  spielten  Bluetooth  und  WLAN  noch  keine  Rolle  und  wurden  des- 
halb  auch  nicht  von  Microsoft  im  Betriebssystem  beriicksichtigt.  Die  Folge  war,  dass  die 
PDA-Anbieter  und  Steckkarten-Hersteller  eigene  Treiber  entwickelten  und  mitlieferten. 
Fur  den  Kunden  hatte  dies  den  Nachteil,  dass  sie  mit  zum  Teil  mangelhaften  Treibern  der 
Hersteller  herumplagen  mussten.  Auch  der  Verbindungsaufbau  mit  VPNs  (Virtual  Pri¬ 
vate  Networks)  ist  erleichtert  worden  und  der  neue  Internetprotokoll- Standard  Ipv6  und 
IPSec/L2TP  wurden  integriert. 
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Veranderungen  von  Windows  Mobile  2003  gegeniiber  Microsoft  Windows  CE: 

•  Drahtlose  Kommunikation  per  Bluetooth  und  WLAN  (Wireless  LAN)  wird  direkt 
vom  Windows  Mobile  2003-Betriebssystem  unterstiitzt. 

•  Komplett  iiberarbeitet  hat  Microsoft  die  Verwaltung  der  Modem-  und  Netzwerkver- 
bindungen. 

•  Niitzliche  Features  erleichtern  in  der  Posteingang-Anwendung  die  Email- Verarbeitung. 

•  Die  Verbesserungen  am  integrierten  Webbrowser  verbergen  sich  unter  der  Oberflache. 

•  Zahlreiche  Verbesserungen  im  Multimedia-Bereich. 

Diese  Betriebssysteme  versteiften  sich  eher  auf  die  PC-ahnlichen  embedded  Systems.  Also 
all  die  Systeme,  die  auf  ein  umfangreiches  Betriebssystem  zuruckgreifen  konnten,  da  es 
keine  Unterbringungsprobleme  gab.  Zur  MS  Embedded  Serie  gehoren  Windows  CE  .NET 
und  Microsoft  Mobile  2003. 

Auch  hier  entstanden  weitere  Anforderungskriterien,  die  sich  durch  die  Entwicklung,  die 
Studien  und  die  Erfahrung  am  Markt  ergeben  hatten.  Es  soil  hier  nur  auf  die  Anfor- 
derungen  [4]  eingegangen  werden,  die  sich  im  Rahmen  der  Arbeiten  an  Windows  Mobile 
2003  zusatzlich  ergeben  haben,  weil  Windows  CE  in  dem  bisherigen  Rahmen  schon  erfasst 
wurde. 

•  Skalierbarkeit 

Keinen  direkten  Einschrankungen  unterworfen,  versuchte  man  naher  an  der  urspriing- 
lichen  PC-Architektur  zu  entwerfen.  Das  Betriebssystem  musste  in  dem  Rahmen  eine 
reiche  Funktionalitat  aufweisen,  aber  vor  allem  eine  Moglichkeit  des  modularen  Auf- 
baus  bieten.  Bei  der  Entwicklung  von  Mobile  2003  legte  Microsoft  besonders  groBen 
Wert  auf  diese  Eigenschaft. 

•  Flexibility 

Das  System  muss  besonders  anpassungsfahig  sein,  wenn  es  auf  keinen  Markt  spezi- 
ell  ausgerichtet  ist.  Theoretisch  musste  es  fur  jedwede  denkbare  mobile  Anwendung 
zuganglich  sein.  Ein  solches  Unterfangen  birgt  eine  groBe  Komplexitat  fur  den  Ent- 
wickler. 

•  umfangreiche  Sicherheit 

Mit  einer  hohen  Skalierbarkeit  und  einer  PC-ahnlichen  Struktur  “gewinnt“  man  auch 
die  Sicherheitsnachteile.  Dahingehend  muss  das  Betriebssystem  wieder  umfangreich 
geschiitzt  werden. 


8.3.3  Linux 

Zunachst  stellt  sich  die  Frage,  warum  gerade  Linux  dazupradestiniert  sein  soil  in  einge- 
betteten  Systemen  eingesetztzu  werden.  Natiirlich  spielen  die  Kosten  eine  grofie  Rolle. 
Da  embedded  systems  in  sehr  grofien  Stiickzahlen  produziert  werden,  sind  schon  geringe 
Lizenzkosten  ein  groBer  Finanzfaktor  fur  den  Hersteller.  Ein  weiterer  Punkt  ist  die  Zuver- 
lassigkeit  des  Systems,  da  auch  hier  Ausfallzeiten  schnell  sehr  teuer  werden  konnen.  Die 
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Systeme  sind  viele  Jahre  im  Einsatz  und  auftretende  Bugs  sollten  ohne  grofiere  Schwie- 
rigkeiten  beseitigt  werden  konnen.  Da  ist  es  natiirlich  besonders  vorteilhaft,  wenn  der 
gesamte  Source  zu  Verfiigung  steht.  Linux  ist  wohl  im  Moment  eines  der  stabilsten  und 
zuverlassigsten  Betriebssysteme  auf  dem  Markt.  Durch  die  open  source  Verbreitung  ist 
es  auch  besonders  flexibel,  wenn  es  darum  geht,  ein  bestehendes  System  auf  ein  anderes 
zu  portieren.  Es  wiirde  viel  Zeit  und  Geld  kosten,  sich  samtliche  Funktionen  miihsam  zu 
erschliefien  und  selbst  zu  programmieren.  Weil  embedded  systems  meist  klein  und  billig 
sein  sollen,  werden  haufig  nicht  mehr  ganz  aktuelle  PC-Komponenten  zu  ihrer  Herstellung 
verwendet.  Das  Betriebssystem  sollte  dann  alles  aus  dieser  “low-power"  Hardware  heraus- 
holen.  Auch  hier  sticht  Linux,  im  Gegensatz  zu  anderen  Betriebsystemen,  durch  seinen 
geringen  Sourcenverbrauch  hervor.  Selbst  Linux  ist  nicht  auf  jeder  Hardware  lauffahig. 
Gewisse  Mindestanforderungen  sollten  schon  gegeben  sein,  damit  das  System  einwandfrei 
funktioniert.  Man  spricht  in  der  Regel  von  einem  Bedarf  von  2  MB  RAM,  2  MB  Flash  und 
einem  32  Bit  Mikroprozessor.  Natiirlich  gibt  es  keine  Regel  ohne  Ausnahme,  es  gibt  bereits 
Linux  Kernel  die  in  80  KB  Speicher  Platz  finden  und  damit  theoretisch  nur  256  KB  RAM 
benotigen  wiirden.  Linux  kann  selbstverstandlich  selbst  bei  sehr  kleinen  Zielsystemen  als 
Entwicklungs-umgebung  eingesetzt  werden,  hierfur  stehen  sehr  viele,  frei  verfugbare,  Soft- 
warewerkzeuge  zur  Verfiigung.  Oft  kann  sogar  das  Testen  der  Software  auf  dem  Zielsystem 
ausbleiben,  da  Linux  die  Hardware  sehr  gut  emulieren  kann.  Das  spart  Entwicklungszeit 
und  damit  viel  Geld.  Eine  weitere  Schwache  des  Standardlinux  ist  seine  nicht  vorhandene 
harte  Echtzeitfahigkeit.  Zwar  iibertrifft  die  implementierte  weiche  Echtzeitunterstiitzung 
die  anderer  Betriebssysteme  bei  Weitem,  aber  fiir  den  industriellen  Einsatz  miissen  In¬ 
terrupt  Antwortzeiten  von  wenigen  Mikrosekunden  gewahrleistet  werden.  Auch  fiir  dieses 
Problem  gibt  es  unter  Linux  eine  Losung,  die  sog.  Betriebssystemerweiterungen.  Hier  hat 
Realtime-Linux  (RT-Linux)  bereits  seine  Industrietauglichkeit  bewiesen.  Linux  stellt  auch 
die  Ausgangslage  fiir  Dutzende  Embedded  Projekte  dar.  So  kann  es  auch  als  Betriebssys¬ 
tem  fiir  mobile  Endprodukte  genutzt  werden.  Besonders  betont  werden  hier  die  folgenden 
Eigenschaften  [3]: 

•  Stabilitat 

Der  Linux  Kernel  weist  bereits  eine  hohe  Stabilitat  und  Ausfallsicherheit  auf  und  ist 
damit  fiir  mobile  Anwendungen  nutzbar  zu  machen.  Das  System  kann  ohne  weiteres 
mehrere  Wochen  und  Monate  ohne  Probleme  laufen  und  wird  daher  auch  in  viele'n 
Bereichen  (z.B.:  Webserver,  etc.)  erfolgreich  eingesetzt.  Abstiirze  sind  in  den  meisten 
Fallen  auf  Hardware-Fehler  oder  die  Stromversorgung  zuriickzufiihren.  Hinsichtlich 
Stabilitat  ist  Linux  den  anderen  vorgestellten  Betriebssystemen  iiberlegen. 

•  Performance 

Das  Betriebssystem  kann  geniigsam  mit  Ressourcen  und  Speicher  umgehen.  Ein  ef- 
fizientes  Management  sorgt  fiir  den  sinnvollen  Einsatz  von  CPU  Power,  Arbeitsspei- 
cher  und  Festplattenspeicher.  Dennoch  ist  dieser  ’Wert’  nur  schlecht  zu  messen.  Eine 
schlechte  Performance  begriindet  sich  in  einem  instabilen  Kern  und  Anwendungen, 
die  auf  einem  solchen  System  ausgefiihrt  werden,  konnen  abstiirzen,  obwohl  die  Soft¬ 
ware  an  sich  einwandfrei  funktioniert.  Um  die  Performance  zu  testen,  kann  man 
Benchmarks  einsetzen.  Diese  Software  versucht  die  Leistung  eines  Systems  mittels 
zahlreicher  Testdurchlaufe  unter  verschiedenen  Bedingungen  zu  ermitteln.  [6]  Dabei 
entsteht  ein  Richtwert,  den  man  mit  anderen  Systemen  vergleichen  kann.  Dieser  Wert 
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ist  stark  abhangig  von  der  Zielanwendung  und  dementsprechend  von  der  Zusammen- 
stellung  des  Betriebssystems. 

•  Skalierbarkeit 

Linux  wird  bereits  auf  unterschiedlichsten  Plattformen  verwendet.  Es  ist  in  der  Lage 
sich  auch  extremen  Bedingungen  anzupassen,  da  es  dank  der  Tatsache,  dass  es  ein 
offenes  Betriebssystem  ist,  in  verschiedenen  Bereichen  angepasst  und  weiterentwickelt 
wurde.  Der  eigentliche  Linux-Kernel  ist  allerdings  iiber  1.5  MByte  grofi.  Mit  weiteren 
Anwendungen  gelangt  man  schnell  auf  mehrere  Megabyte.  Damit  das  System  fur 
mobile  Systeme  genutzt  werden  kann,  muss  man  sich  die  Modularitat  nutzbar  machen 
und  den  Kernel  feiner  konfigurieren.  Dadurch  kann  man  Werte  im  Bereich  von  300 
Kilobyte  erreichen.  Und  auch  wenn  der  Kernel  mit  TCP/IP  um  die  500  Kilobyte 
grofi  ist,  so  ist  der  memory  footprint  immer  noch  akzeptabel. 

•  Portabilitat  (Offenes  System) 

Linux  hat  bereits  eine  breite  Nutzung  auf  unterschiedlichen  Plattformen  erreicht,  so 
dass  man  in  der  Entwicklung  des  Betriebssystems  darauf  fokussiert  war,  die  Kompa- 
tibiltat  zu  moglichst  vielen  Plattformen  zu  forcieren.  Dadurch  wird  durch  eine  neue 
Hardware  nicht  zwangsweigerlich  ein  neues  Betriebssystem  benotigt.  Zudem  fordert 
die  Tatsache,  das  Linux  ein  offenes  System  ist,  die  Entwicklung  durch  eine  breite 
Front  an  mitwirkenden  Herstellern  und  auch  Benutzern. 

•  Echtzeit-Verhalten 

Linux  ist  von  sich  aus  nicht  in  der  Lage  in  Echtzeit  zu  reagieren.  Prozesse  miissen 
im  Queue  warten,  damit  andere  Prozesse  beendet  werden  konnen  oder  wiederum 

•  auf  den  Queue  gelegt  werden.  Die  Losung  dieses  Problems  liegt  in  dem  Versuch 
einen  RT-Kernel  zu  erstellen,  der  genau  dieses  Echtzeit-Verhalten  an  den  Tag  legt. 
LynxOS  ist  ein  Linux-basiertes  Betriebssystem,  das  Echtzeiteigenschaften  nach  dem 
Standard  DO-178B  aufweist.  Dieser  Standard  ist  in  den  Vereinigten  Staaten  die  Vor- 
aussetzung  fur  samtliche  Software  im  Bereich  der  Flugtechnik  und  ein  embedded  Sys¬ 
tem  muss  diese  Mindes'tanforderungen  erfiillen.  Die  Realisierung  wird  beispielsweise 
durch  Partitionierung  und  eine  abstrakte  Zuordnung  durchgefiihrt.  Dabei  werden 
den  Anwendungen  einzelne  Bereiche  zugeordnet,  damit  sie  praktisch  in  einer  eige- 
nen  Betriebssystemumgebung  operieren  konnen  und  theoretisch  eine  ’eigene  CPU’ 
beanspruchen. 


Zudem  wird  der  Linux  Kernel  fortwahrend  weiterentwickelt  und  dieser  Prozess  vollzieht 
sich  sehr  schnell.  Die  neuesten  Kernel  Designs  beinhalten  wie  schon  erwahnt  Modularitat. 
Das  bedeutet,  dass  der  Kern  selbst  sehr  klein  gehalten  wurde  und  die  Erweiterungen 
komponentenweise  erganzt  werden.  Gerade  in  diesem  Bereich  herrscht  zwischen  den  Linux- 
und  den  Windows-  Anhangern  ein  reger  Diskussionsbedarf.  Und  auch  wenn  durch  einige 
neuere  Abhandlungen  die  Windows  Embedded  Serie  von  verschiedenen  Firmen  mit  Linux 
Embedded  Systemen  im  Vergleich  als  schlechter  dargestellt  wird,  so  kann  Windows  Mobile 
2003  durchaus  als  argumentative  Grundlage  fur  die  Skalierbarkeit  eines  Systems  dienen. 
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8.4  Aufbau  am  Beispiel  von  Symbian 


In  diesem  Teil  soli  der  Aufbau  eines  Betriebssystems  fur  mobile  Systeme  erlautert  werden. 
Dabei  wird  das  Betriebssystem  von  zwei  Seiten  betrachtet.  Die  eine,  die  Hardware-Sicht, 
beschaftigt  sich  ausfiihrlich  mit  der  benotigten  Hardware  zum  einen  und  der  programm- 
technischen  Losung  zum  anderen.  Eine  zweite  Sicht  wirft  die  der  Applications  auf.  Dadurch 
erhalt  man  einen  besseren  Zilgang  zu  den  einzelnen  Anwendungen  und  ihre  Abhhngigkei- 
ten.  Weiterhin  soli  das  Zusammenspiel  der  einzelnen  Teile  erlautert  und  der  modulare 
Aufbau  eines  Betriebssystems  erklart  werden.  Es  wird  auf  die  Skalierbarkeit  und  auch  die 
unterschiedliche  Bandbreite  eines  solchen  Systems  hingewiesen. 


8.4.1  Hardware-Sicht 

In  diesem  Kapitel  soil  auf  drei  Aspekte  der  Hardware-Sicht  naher  eingegangen  werden. 
Dies  sind  im  Einzelnen 

•  der  Hardware-Aufbau  und  damit  die  Positionsbestimmung  der  Einzelteile 

•  der  Aufbau  des  Betriebssystems  und  damit  die  Funktionsweise  der  Einzelteile 

•  und  zuletzt  der  Betriebssystemkern  selbst,  der  fur  die  Kontrolle  und  Steuerung  der 
Einzelteile  zustandig  ist 

Hardware-Aufbau 

Die  3-Layer-Architektur  setzt  drei,  standardisierte  Ebenen  als  Grundlage  voraus  (siehe 
Abbildung  1).  Dadurch  wird  das  Zusammenspiel  einzelner  Komponenten  erleichtert  und 
der  Befehlssatz  des  Betriebssystems  optimiert. 

•  First  Layer  -  CPU  Core 

Auf  der  ersten  Ebene,  dem  Kern  des  Systems,  befindet  sich  eine  schnelle  und  kosten- 
giinstige  CPU,  die  zudem  nur  wenig  Energie  verbraucht.  Neben  dem  zentralen  Pro- 
zessor  befinden  sich  hier  auch  solche  grundlegenden  Einrichtungen  wie  die  Memory 
Management  Unit  (MMU)  und  die  Caches.  Symbian  OS  setzt  eine  integrierte  MMU 
und  einen  Cache  voraus,  um  privilege  levels  zu  ermoglichen.  Mit  Interrupts  und  Ex¬ 
ceptions  wird  somit  eine  Prioritatencodierung  zuganglich,  die  in  der  Form  benotigt 
wird,  um  den  schnellen  und  problemlosen  Ablauf  von  Prozessen  zu  gewahrleisten. 
Zur  Erlauterung  der  einzelnen  Begrifflichkeiten  sei  hier  auf  Fachliteratur  verwiesen. 

[5] 

Main  Memory  Unit 

An  dieser  Stelle  soli  das  Konzept  der  Virtual  Machine  Environment  (VME)  geschil- 
dert  werden.  Es  dient  dazu,  um  Prozesse  mit  Hilfe  der  MMU  im  virtuellen  Adress- 
raum  zu  verschieben  (siehe  Abbildung  2).  Dadurch  kann  schon  im  voraus  Speicher- 
bedarf  berechnet  werden  und  man  spart  sich  wiederum  Zeit  und  Belastung  der  CPU, 
in  dem  man  die  Daten  nach  einer  Loschung  erneut  laden  miisste[8]. 
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Abbildung  8.1:  Die  3-Layer- Architektur.  [8] 

Cache  und  Speicher 

Eine  weitere  wichtige  Frage  fur  die  Unterbringung  von  Daten  und  des  Betriebssys- 
tems  selbst  ist  die  nach  dem  Speicher.  Nur  ein  geringer  Teil  des  Speichers  ist  on-chip 
verfiigbar.  Der  grofite  Teil  liegt  auBerhalb  des  Hardwarekerns  und  wird  off-chip- 
memory  genannt.  Dieser  hat  vor  allem  die  Aufgabe  das  Symbian  OS  image  (siehe 
weiter  unten)  zu  speichern,  damit  die  CPU  darauf  standigen  Zugriff  hat.  Weiterhin 
werden  alle  anderen  wichtigen  Daten  (User-,  Prozessdaten)  hier  gespeichert.  In  Be- 
zug  auf  verschiedene  Speicherbausteine,  deren  Vor-  und  Nachteile  sei  auch  an  dieser 
Stelle  wieder  an  geeignete  Fachliteratur  von  [5]  verwiesen.  Es  soli  an  dieser  Stelle 
geniigen,  dass  diese  Problematik  in  den  meisten  Fallen  durch  Flash  Memory  gelost 
wird.  Dieser  ist  zwar  sehr  teuer,  dafiir  aber  auch  schnell  und  wiederbeschreibbar. 

•  Second  Layer  -  SoC 

Die  CPU  wird  wiederum  auf  einen  Chip  integriert  und  stellt  mit  ihm  zusammen 
die  zweite  Ebene  dar.  Dieser  integrale  Bestandteil  tragt  den  Namen  system-on-chip 
(SoC)  und  beinhaltet  samtliche  lebenswichtigen  Peripherigerate  fiir  das  Betriebssys- 
tem.  So  zum  Beispiel  auch  die  Timer,  den  DMA  Controller  und  vieles  mehr. 

•  Third  Layer  -  PCB 

Auf  der  dritten  Ebene  werden  alle  restlichen  Komponenten,  die  das  eigentliche  End- 
produkt  ausmachen,  angelegt.  Zusammengefasst  tragt  sie  den  Namen  Printed  Circuit 
Board  (PCB). 

Aufbau  des  Betriebssystem  -  Das  Symbian  OS  image 

Das  eigentliche  Betriebssystem  wird  im  Symbian  OS  image  gespeichert.  Es  besteht  aus 
sogenannten  dynamic  linked  libraries  (DLL)  und  vielen,  weiteren  Dateitypen.  Weitere  Da- 
teien  sind  zum  Beispiel  Fonts,  Bitmaps  und  andere.  Die  DLLs  bilden  die  Kernsubstanz 
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Abbildung  8.2:  Die  Virtual  Machine  Environment.  [8] 


des  Systems  und  sind  der  wichtigste  Schritt  zur  Losung  des  Problems  der  Geschwindigkeit 
und  Flexibilitat  eines  Systems.  Innerhalb  dieser  Dateien  befinden  sich  wichtige  Codeseg- 
mente,  die  sich  durch  ausfiihrbare  Dateien  aufrufen  lassen.  Durch  Wiederverwendung  und 
haufige  Kopplung  kann  so  Speicherplatz  und  Ladezeit  gespart  werden.  Der  CPU  fiihrt  das 
Betriebssystem  direkt  an  seinem  Speicherort  aus.  Falls  das  aber  zu  langsam  sein  sollte, 
kann  man  bestimmte  Bibliotheken  in  den  Random  Access  Memory  kopieren.  Dort  kon- 
nen  sie  dann  genutzt  und  notigenfalls  mit  mehreren  Prozessen  verbunden  werden.  Mittels 
eines  speziellen  Schliisselverfahrens  konnen  zahlreiche  DLLs  mit  Anwendungen  verbun¬ 
den  und  gleichzeitig  die  GroBe  der  Libraries  minimiert  werden.  [8]  Im  Falle  von  Symbian 
OS  wird  ein  spezieller  DLL  Typ  haufig  eingesetzt-  polymorphic  DLL.  Diese  Bibliotheken 
sind  mit  der  Nutzbarmachung  der  objekt-orientierten  Programmierung  entstanden.  An 
der  ersten  Position  in  der  DLL  steht  eine  Methode  zum  Aufruf  der  bestimmten  Klasse. 
Beispielsweise  kann  man  in  der  application  DLL  mit  NewApplication()  eine  Instanz  einer 
Anwendung  aufrufen.  [8]  Im  Sinne  der  Polymorphic  hangt  das  Ergebnis  des  Aufrufs  einer 
Methode  von  der  Klasse  ab,  die  die  Methode  nutzen  will.  Beispielsweise  fiihrt  zeichneQ 
bei  dem  Aufruf  durch  die  Klassen  Dreieck  und  Quadrat  zu  unterschiedlichen  Ergebnissen, 
obwohl  in  beiden  Fallen  auf  dieselbe  Operation  zugegriffen  wurde. 

Steuerung  und  Kontrolle  -  Der  Symbian  Kernel 

Der  Symbian  Kernel  (Betriebssystemkern)  ist  weniger  als  200  KB  grofi.  Im  Verhaltnis  zu 
anderen  Systemen  ist  das  ein  sehr  guter  Wert.  Trotz  des  kompakten  Baus  unterstiitzt 
er  beispielsweise  Multitasking  und  ist  fast  vollstandig  von  peripheren  Geraten  unabhan- 
gig.  Die  Hardwareunterstiitzung  wird  iiber  DLLs  geregelt,  die  verschiedene  Komponenten 
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ansprechen  konnen.  Dabei  wird  eine  dynamische  An-  und  Abkopplung  dieser  Elemente 
unterstiitzt  und  fordert  somit  die  Kompatibilitat.  Dabei  wird  der  benotigte  Code,  um  ei¬ 
ne  bestimmte  Hardware  anzusprechen,  in  abgegrenzte  Bibliotheken  gespeichert.  Das  setzt 
unter  anderem  eine  intelligente  Programmierung  und  eine  zukunftsorientierte  Planting 
voraus.  Auf  die  entsprechenden  Hardwarebereiche  kann  nur  im  privileged  mode  zugegrif- 
fen  werden,  was  den  Missbrauch  durch  andere  Gerate  verhindert.  Da  der  Kernel  immer  in 
diesem  Modus  ausgefiihrt  wird,  hat  er  samtlichen  Zugriff  zu  alien  Bereichen.  Anwendun- 
gen  greifen  iiber  Schnittstellen  auf  Kernel  Dienste  zu.  Dies  wird  durch  APIs  (Application 
Programming  Interface)  realisiert  und  durch  die  Benutzerbibliothek  unterstiitzt.  Samt- 
liche  Anwendungen  laufen  im  unprivileged  mode  und  konnen  daher  auch  auf  keinerlei 
Hardwarebereiche  zugreifen.  Benotigen  sie  diesen  Zugang,  dann  muss  diese  Anwendung 
entweder  die  Berechtigung  durch  Mode-Switching  erhalten  oder  iiber  den  Kernel  Server 
vermittelt  werden.  Ein  weiterer  wichtiger,  zentraler  Bestandteil  des  Betriebssystemskerns 
ist  die  Kernel  Library.  Hier  werden  alle  lebensnotwendigen  Protokolle  gespeichert,  um 
die  Kommunikation  zu  den  wichtigsten  peripheren  Geraten  sicherzustellen  (bspw.  DMA 
Controller,  Timer,  etc.).  Diese  Bibliotheken  sind  allerdings  auch  chipabhangig.  Peripherie, 
die  mit  einer  Usereingabe  im  Zusammenhang  steht,  kann  wiederum  in  separaten  DLLs 
gepackt  werden  -  die  sogenannten  Kernel  Extensions.  Verschiedene  Kernel  Extensions 
konnen  fur  Tastatur  und  viele  mehr  geschrieben  werden.  Die  entsprechenden  Extensions 
werden  dem  Symbian  OS  Image  hinzugefiigt,  wobei  der  Kernel  ihre  Anwesenheit  fest- 
stellt  und  beim  Booten  initialisiert  (siehe  Abbildung  3).  Jeder  Zugriff  auf  die  Hardware 
wird  iiber  den  Kernel  geregelt.  Die  sonstigen  Zugriffe  werden  ebenfalls  durch  den  Kernel 
gesteuert. 


Abbildung  8.3:  Der  interne  Aufbau  des  Betriebssystems..  [8] 
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Der  Kernel  selbst  hat  keinerlei  Abhangigkeit  von  diesen  Erweiterungen  und  auf  die  Ker¬ 
nel  Extensions  erhalt  keine  Anwendung  selbst  den  Zugriff.  Damit  nun  die  Anwendungen 
korrekt  funktionieren  und  die  fur  sie  vorgesehene  Hardware  benutzen,  sind  just  diese  Infor- 
mationen  in  den  Treibern  gespeichert.  Diese  konnen,  um  die  Kontrolle  iiber  die  Hardware 
fur  bestimmte  Anwendungen  zu  erhalten,  beliebig  installiert  und  deinstalliert  werden.  Die 
Treiber  bestehen  aus  zwei  Teilen,  einer  Bibliothek,  um  die  entsprechende  API  selbst  an- 
zusprechen  und  mehreren  Bibliotheken,  um  die  Hardware  nutzen  zu  konnen.  Damit  kann 
die  Kontrolle  partiell  vermittelt  werden,  ohne  direkten  Einfluss  oder  Schaden  am  Kernel 
beziehungsweise  dem  Betriebssystem  selbst  vorzunehmen.  An  dieser  Stelle  soil  noch  ein- 
mal  naher  auf  die  Kernel  Side  Library  eingegangen  werden.  Es  wurde  ja  bereits  gesagt, 
dass  hier  alle  lebensnotwendigen  Daten  gespeichert  sind.  Diese  Bibliotheken  unterteilen 
sich  allerdings  noch  einmal  in  zwei  verschiedene  Typen.  Zum  einen  gibt  es  den  logical 
device  driver  DLL  (LDD)  und  zum  anderen  den  physical  device  driver  DLL  (PDD).  Die 
logischen  Treiber  beinhalten  samtliche  grundlegenden  logischen  Funktionen  im  Sinne  von 
I/O.  Diese  sind  auch  immer  auf  andere  Systeme  transportierbar.  Der  interessante  Aspekt 
sind  die  PDD,  die  jeweils  auf  das  bestimmte  Zielsystem  zugeschnitten  werden  und  die 
vorhandenen  Ressourcen  mobilisieren  konnen.  Diese  Dateien  sind  notwendig  und  miissen 
verfiigbar  sein,  aber  durch  die  Zweiteilung  muss  man  bei  dem  Portieren  des  Betriebs- 
systems  auf  einer  andere  Hardware-Plattform  nur  die  entsprechenden  PDD  austauschen 
und  das  System  funktioniert  in  der  gewiinschten  Umgebung.  LDD  und  PDD  sind  hier  als 
polymorphic  DLL  realisiert  und  miissen  in  einem  bestimmten  Verfahren  genutzt  werden. 
[8]  Einzige  Ausnahme  aus  der  Prioritatseodierung  ist  der  Screen  Buffer.  Das  erscheint 
auch  logisch,  wenn  man  bedenkt,  dass  die  Bildschirmdarstellung  sich  nicht  “hinten  anstel- 
len“  sollte.  Die  Losung  liegt  im  Direct  Memory  Access,  der  die  Daten  unmittelbar  in  das 
LCD  Display  kopiert.  Damit  es  an  Schnelligkeit  nicht  mangelt,  wurde  der  Screen  Buffer 
mit  alien  notwendigen  Lese-  und  Schreibberechtigung  auf  alle  Prozesse  ausgestattet.  Da¬ 
mit  werden  Anwendungen  iiber  eine  Graphic  API  schnell  dargestellt.  Folglich  wird  der 
privileged  mode  umgangen  und  dieser  Vorgang  liegt  aufierhalb  der  Prioritatencodierung. 


8.4.2  Application-Sicht 

Symbian  OS  wurde  als  ein  umfangreiches  Betriebssystem  geplant,  welches  alle  Fahigkeiten 
eines  normalen  Betriebssystem  aufweist  und  dennoch  in  den  Speicher  eines  Mobiltelefons 
passen  sollte.  [8]  Das  setzt  bestimmte  Anforderungen  voraus.  Diese  wurden  nun  bereits 
genannt  beziehungs-weise  auch  erlautert  und  teilweise  auch  diskutiert.  Im  Zusammenhang 
des  Aufbaus  wird  nun  die  zweite  Sichtweise  betrachtet.  Diese  Sicht  beschaftigt  sich  vor 
allem  mit  den  Abhangigkeiten  der  Systemkomponenten.  Es  handelt  sich  allerdings  um 
einen  Ubergang  und  eine  klare  Trennung  zwischen  den  Sichtweisen  kann  nicht  vorgenom- 
men  werden.  So  miissen  zunachst  noch  einige  tiefer  gehende  Erlauterungen  vorangehen, 
bevor  man  sich  dem  allgemeinen  Aufbau  aus  der  Application-Sicht  zuwenden  kann. 

Server- Client  Struktur 

Symbian  OS  beinhaltet  eine  umfassende  Sammlung  an  Bibliotheken,  um  moglichst  viele 
Industriestandards  zu  implementieren.  Unter  anderem  TCP/IP,  SSL,  FTP  und  SMTP  um 
nur  einige  aus  verschiedenen  Bereichen  zu  nennen.  Abbildung  4  zeigt  einige  Bereiche  auf, 
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Abbildung  8.4:  Dienste  innerhalb  der  Symbian  OS  Technologies.  [8] 


die  diese  Standards  innerhalb  des  Betriebssystems  implementiert  haben.  Diese  Dienste 
werden  liber  eine  einfache  Server-Client  Struktur  eingebaut. 

Der  Server  Thread  lauft  im  unprivileged  mode  und  jede  Anwendung  kann  als  Client  liber 
eine  Standardschnittstelle  mit  einem  Server  durch  den  Kernel  Kontakt  aufnehmen.  Dieser 
Befeich  gehort  zu  dem  bereits  erwahnten  Konzept  der  Prioritatencodierung.  Die  Nutzung 
dieser  Client-Server  Architektur  in  diesem  Betriebssystem  beinhaltet  beispielsweise  den 
file  server  und  den  media  server.  Anhand  des  media  server  folgt  nun  ein  kleines  Beispiel  fur 
eine  Komponente  (media  codec),  die  durch  das  client-server  System  angesprochen  wird. 
Abbildung  5  zeigt  die  Vermittlung  zwischen  zwei  Anwendungen  durch  den  Kernel.  Der 
Kernel  vermittelt  zwischen  beiden  Komponenten  und  gewahrt  den  Zugang  zur  Hardware. 

Externe  Anwendungen 

Eine  weitere  Schicht  in  diesem  Zusammenhang  ist  die  der  externen  Anwendungen.  Das 
beinhaltet  unter  anderem  das  Adressbuch,  Editoren  u.v.m..  Auf  dieser  Ebene  ist  auch 
das  Grundgerlist  fur  die  GUI  (Graphical  User  Interface)  implementiert.  Es  ist  bewusst 
keine  komplette  Oberflache  erstellt  worden,  um  dem  jeweiligen  Hersteller  eine  individuelle 
Anpassung  zu  ermoglichen. 

Weitere  Dienste 

Im  Querschnitt  werden  nun  weitere  Dienstleistungen  des  Betriebssystem  angefiihrt.  Abbil¬ 
dung  6  verdeutlicht  die  Abstufungen  untereinander,  statt.  der  detaillierten  Schnittstellen- 
losungen.  Die  Abbildung  soil  dazu  dienen,  um  eine  komplette  Ubersicht  liber  die  Kompo¬ 
nenten  von  Symbian  OS  7.x  zu  erhalten.  Man  konnte  vermuten,  dass  einige  Komponenten 
nur  integrierbar  sind,  wenn  einige  Subsysteme  bereits  vorhanden  sind.  Das  stimmt  nur 
bedingt  und  wird  nach  der  genaueren  Auflistung  genauer  erlautert.  Auf  der  anderen  Seite 
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Abbildung  8.5:  Der  Zugriff  auf  eine  Hardwarekomponente  durch  den  media  server.  [8] 


konnen  auch  hierarchisch,  hohere  Systeme  installiert  werden,  wenn  andere,  die  horizontal 
verschoben  sind,  nicht  vorhanden  sind. 

Die  Komponenten  und  ihre  Subsysteme  dieser  Sichtweise  sind  folgende: 


•  Base 

Hier  sind  die  grundlegenden  Basiseinrichtungen  implementiert.  Dieser  Bereich  wurde 
bereits  ausfiihrlich  in  der  Hardwaresicht  erlautert.  Bestandteile  sind: 

Der  Kernel  und  die  Benutzerbibliotheken 
Die  lebenswichtigen  Peripheriegerate 
Sicherheitssysteme 

•  Telephony 

Kommunikation  wird  im  Sinne  von  Verbindungen  iiber  Weitverkehrsnetze  verstan- 
den.  Mit  Telefonie  sind  Anwendungen  und  der  Zugriff  auf  anwendungsspezifische 
Systemparameter  gemeint.  Fur  Anwendungen  aus  der  Telefonie  stehen  APIs  zur  Ver- 
fiigung,  die  die  grundsatzlichen  Eigenschaften  der  unterschiedlichen  zellularen  Netze 
abstrahieren  (GSM,  GPRS,  EDGE,  CDMA  als  amerikanisches  Aquivalent  zu  GSM, 
bzw.  die  Varianten  von  UMTS).  Auf  diese  Weise  Iassen  sich  Anwendungen  zwischen 
den  unterschiedlichen  Telefonstandards  leichter  portieren.  Zu  den  gemeinsamen  Ei¬ 
genschaften  gehoren  Informationen  iiber  Netze  und  iiber  das  Endgerat  (Empfangs- 
qualitat,  Ladezustand  der  Batterie,  Kennungen  der  empfangenen  Netze,  Informatio¬ 
nen  iiber  das  jeweils  genutzte  Netz,  Benachrichtigungen  iiber  Veranderungen,  Ken- 
nung  des  Endgerates),  sowie  der  Zugriff  auf  Telefonverzeichnisse  im  Endgerat  und  in 
der  SIM-Karte 
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Abbildung  8.6:  Struktur  und  Aufbau  des  Symbian  OS  7.x  [8] 


•  Security 

Stellt  verschiedene  Sicherheitsmechanismen  zur  Verfiigung. 

•  Application  framework 

In  diesem  Bereich  sind  die  meisten  wiederverwendbaren  DLLs  untergebracht,  die 
sogenannte  Middleware  API.  Middleware  API  sind  Schnittstellen  zur  Bereitstellung 
von  erweiterten  Leistungen.  Sie  unterstiitzen  Dateimanagement,  Text,  Grafiken  und 
neben  einigen  anderen  Features  auch  die  Kern-GUI  Komponenten. 

•  Multimedia 

Der  media  server  stellt  eine  weitere,  externe  Komponenten  dar,  die  dem  Betriebssys- 
tem  zuganglich  gemacht  wurde.  Damit  ist  unter  anderem  die  Aufnahme  von  Audio- 
stiicken  moglich.  Der  media  server  wurde  bereits  im  Zusammenhang  mit  der  Server- 
Client  Struktur  erwahnt. 

•  Communication  infrastructure 

Hier  sind  alle  Protokolle  wie  TCP/IP,  GSM,  GPRS  und  WAP  untergebracht.  Weitere 
Kommunikationsmoglichkeiten  sind  Infrarot,  Bluetooth  und  Seriell.  Zur  Kommunikations- 
infrastruktur  gehoren  ein  Datenbankmanager  fur  die  Systemkonfiguration,  Socket- 
Server  und  Schnittstellenmanager  mit  APIs  als  Geriist  fiir  Kommunikations-nanwendungen, 
sowie  Kommunikationsserver  fiir  serielle  Verbindungen  und  fiir  Verbindungen  liber 
WAP  und  HTTP.  Die  IP-Umgebung  unterstiitzt  sowohl  IPv4  und  IPv6  Adressen, 
sowie  alle  relevanten  Protokolle  aus  dem  IP-Stack  (wie  z.B.  TCP,  UDP,  ICMP,  PPP, 

TLS,  SSL  und  Unterstiitzung  fiir  DNS).  Ebenfalls  vorhanden  sind  FTP,  Telnet,  sowie 
IPSec  fiir  VPN-Clients.  Der  HTTP-Stack  wird  z.B.  fiir  Anwendungen  iiber  GRPS 
verwendet,  bzw.  fiir  SynchML  oder  die  Ubertragung  von  Streaming  Medien  iiber 
TCP/IP.  Der  WAP-Stack  wird  fiir  Anwendungen  iiber  GSM,  GPRS,  CDMA  und 
UMTS  verwendet  und  unterstiitzt  auch  Push-Dienste. 
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•  Personal  area  networking 

Zum  Personal  Area  Network  gehoren  der  Bluetooth  Protokollstack  mit  dem  Generic 
Access  Profil  (GAP),  dem  Serial  Port  Profil  (SPP)  und  dem  Gerneral  Object  Ex¬ 
change  Profil  (OPEX),  sowie  die  Moglichkeit  zur  Vernetzung  via  Infrarot  (IrDA)  und 
USB. 

•  Messaging 

Zu  den  unter  Messaging  zusammengefassten  Funktionen  gehort  die  Unterstiitzung 
fur  SMS,  EMS,  MMS,  E-Mail  und  FAX.  Die  Behandlung  der  unterschiedlichen 
Messaging-Formate  ist  grundsatzlich  gleich.  Eine  EMS  ist  ein  gegeniiber  der  SMS 
erweitertes  Format  (Enhanced  Messaging  Service),  das  Bilder  und  Tone  unterstiitzt 
und  nach  Art  der  SMS  innerhalb  der  Mobilfunknetze  iibertragen  wird.  Eine  MMS 
wird  nach  Art  einer  E-Mail  iiber  WAP  oder  HTTP  transportiert.  Die  Messaging- 
Gruppe  ermoglicht  das  Schicken  von  Nachrichten  direkt  aus  anderen  Anwendungen, 
wie  z.B.  das  Versenden  einer  Visitenkarte  (vCard)  direkt  aus  dem  Teilnehmerver- 
zeichnis. 

•  Application  engines 

Dieser  Bereich  deckt  viele  weitere  Anwendungen  ab,  die  als  “nice-tohave“  eingebaut 
wurden.  Unter  anderem  zum  Beispiel  ein  Terminkalender,  To-Do  Listen  oder  ahnli- 
ches. 

•  CLDC 

CLDC  bedeutet  so  viel  wie  Connected  Limited  Device  Configuration  und  beschreibt 
die  Eigenschaften  der  Gerate  im  Low-End  Bereich.  Ausser  diesen  Konfigurationen, 
die  generelle  geratespezifische  Eigenschaften  beriicksichtigen,  gibt  es  weitere  Modelle 
fur  verschiedene  Anwendungsklassen  oder  Anwendungsprofilen  dieser  Konfiguratio¬ 
nen.  Unter  den  Low-End  Geraten  unterscheidet  sich  das  Profil  eines  Spielzeugautos 
von  dem  der  Waschmaschine  oder  dem  eines  Mobiltelefons.  Die  APIs  und  Biblio- 
theken  der  Konfigurationen  werden  durch  die  APIs  und  Bibliotheken  der  Profile  fur 
den  jeweiligen  Anwendungszweck  erganzt.  Fur  die  Erstellung  von  Anwendungen  auf 
Mobiltelefonen  ist  das  Mobile  Information  Device  Profile  (MIDP)  interessant.  Die 
zugehorigen  Anwendungen  werden  als  Midlets  bezeichnet. 

•  Java  MIDP 

Vergleiche  Kapitel  8.6  Java  2  Micro  Edition  (J2ME)  -  Java  Umgebung  fur  Embedded 
Anwendungen 

Die  verschiedenen  Bereiche  stellen  Basiskomponenten  dar,  auf  denen  die  Anwendungen 
wie  beschrieben  aufbauen  beziehungsweise  integriert  werden  konnen.  Das  Diagramm  zeigt, 
bei  den  oben  beschriebenen  Komponenten  eine  gewisse  horizontale,  als  auch  vertikale 
Zugehorigkeit.  [8]  Es  sei  an  dieser  Stelle  noch  darauf  hingewiesen,  dass  dieser  getrennte 
Aufbau  und  die  strikte  Trennung  der  Anwendungen  dazu  fiihrt,  dass  die  Stabilitat  des 
Systems  gewahrleistet  werden  kann.  Gleichsam  kann  das  Betriebssystem  voll  operations- 
und  multitaskingfahig  sein. 
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8.5  Bewertung 


Dieser  Teil  der  Ausarbeitung  beschaftigt  sich  mit  dem  Vergleich  von  Betriebssystemen  und 
einer  Bewertung  der  hier  vorgestellten  Systeme.  Der  Vergleich  zu  gangigen  Betriebssys¬ 
temen  kann  hauptsachlich  durch  eine  Thematisierung  erfolgen.  Dabei  wiirde  man  auf  der 
Seite  der  gangigen  Betriebssysteme  das  Schlagwort  Generalisierung  und  auf  der  anderen 
Seite  die  Spezialisierung  einfiihren.  Gangige  Betriebssysteme  sind  fur  viele,  verschiedene 
Anwender  und  Plattformen  gedacht.  Es  sollen  moglichst  zahlreiche  Funktionen  zuganglich 
sein,  da  anhand  dieser  der  Marktpreis  errechnet  wird.  Im  Grofien  und  Ganzen  konnte  man 
das  zwar  auch  bei  den  Betriebssystemen  fur  mobile  Systeme  sagen,  allerdings  ist  es  im 
Rahmen  der  Anforderungen  nur  bedingt  moglich  dem  nachzukommen.  Natiirlich  soli  auch 
ein  Mobiltelefon  ein  breites  Anwendungsspektrum  aufweisen,  allerdings  erwartet  man  von 
einem  Handy  beispielsweise  keinen  Raytracer.  Ubergreifend  wurde  bereits  gezeigt,  dass 
sich  ein  Betriebssystem  fur  eine  mobile  Anwendung  von  einem  gangigen  Betriebssystem 
in  den  speziellen  Anforderungen  unterscheidet.  Heutzutage  werden  aber  in  vielen  Berei- 
chen  bereits  normale  Betriebssysteme  in  Abwandlungen  oder  als  Basis  genutzt,  um  sie  in 
mobilen  Endsystemen  einzusetzen. 

Vorausschauende  Planung 

Beginnend  beim  Aufbau  unterscheidet  sich  dieser  insofern,  dass  die  hier  vorgestellten  Sys¬ 
teme  besser  durchdacht  und  geplant  sind.  Fehler  sind  in  diesem  Marktsegment  unzulassig 
und  enorme  Anforderungen  heben  sie  von  den  normalen  Systemen  ab.  Vorausschauen¬ 
de  Planung  ist  bei  derartigen  Betriebssystemen  insofern  notwendig,  da  die  Entwicklung 
standig  fortschreitet  und  die  einzelnen  Systeme  noch  eine  Kompatibilitat  aufweisen  sollen. 

Architektur 

Insgesamt  fallt  die  Architektur  kleiner,  aber  auch  geplanter  aus.  Das  wiederum  erkennt 
man  auch  beim  Powermanagement.  Ein  fester  Stromzugang  ist  meistens  nicht  moglich 
und  ein  grofies  Netzteil  undenkbar.  Die  Auswahl  von  Bausteinen  (Speicher,  CPU,  etc.)  ist 
in  mobilen  Endprodukten  begrenzter,  allerdings  von  ihrer  Bedeutung  her  der  Hardware 
bei  gangigen  Systemen  sehr  ahnlich.  Zumeist  hat  man  nicht  soviel  Platz  fur  zusatzliche 
Hardware  und  muss  mit  dem  auskommen  was  vorhanden  ist. 

Kernel 

Der  Kernel  in  Betriebssystemen  ftir  mobile  Systeme  ist  aufiert  kompakt  und  schnell  aus- 
fiihrbar.  In  diesem  Zusammenhang  wurde  auch  die  Ankopplung  von  zusatzlichen  Anwen- 
dungen  anhand  Symbian  OS  gezeigt.  Der  Betriebssystemkern  ist  entsprechend  ’Stand- 
Alone’  ausgelegt  und  kann  mit  passenden  Modulen  erganzt  und  aufgewertet  werden. 

Schnittstellen  und  Peripherie 

Ein  weiterer  Bereich  ist  der  der  Schnittstellen.  Wahrend  in  gangigen  Systemen  Peripherie- 
gerate  fiber  beispielsweise  das  Plug  &  Play-System  angesteuert  beziehungsweise  installiert 
werden,  ist  in  dem  Bereich  mobiler  Systeme  zumeist  nicht  soviel  Platz  fur  Steckplatze  fur 
Erweiterungskarten.  Die  Ansteuerung  von  solchen  Zusatzen,  die  wiederum  klein  ausfal- 
len,  muss  sich  hier  grofitenteils  auf  Softwareebene  abwickeln  lassen.  Man  will  Platz  und 


Michael  Bohm 


185 


unnotige  Wege  sparen.  Notfalls  kann  das  System  allerdings  auch  ganzlich  ohne  weitere 
Anwendungen  und  Peripherie  arbeiten.  Falls  in  einem  gangigen  Betriebssystem  eine  wich- 
tige  Erweiterung  fehlerbehaftet  ist,  kann  es  zu  Abstiirzen  kommen.  Gerade  bei  embedded 
Systemen  ist,  wie  zuvor  erlautert,  ein  Eingriff  in  das  System  nicht  moglich  und  wiirde  hier 
zu  vorerst  irreparablen  Schaden  fiihren. 

Erreichbarkeit 

Gangige  Betriebssysteme  konnen  auf  etablierte  Protokolle  zuriickgreifen,  wahrend  mobile 
Anwendungen  grundsatzlich  wireless  bleiben  miissen. 

Echtzeit-  Verhalten 

Die  Echtzeiteigenschaften  sind  bei  vielen  mobilen  Anwendungen  ein  Muss,  wahrend  gan¬ 
gige  Betriebssysteme  fast  ganzlich  darauf  verzichten.  Allerdings  ist  es  mittlerweile  laut 
einiger  Hersteller  ’problemlos’  moglich  ihr  System  mit  Echtzeiteigenschaften  auszustat- 
ten.  [4].  Auch  die  neuesten  Version  von  Symbian  OS  soli  Echtzeiteigenschaften  besitzen. 

Im  Zusammenhang  auf  die  Bewertung  interessieren  folgende  Aspekte: 

•  Kann  man  die  Systeme  miteinander  vergleichen  beziehungsweise  welchen  Sinn  kann 
das  haben? 

•  Welche  Vor-  und  Nachteile  beherbergen  die  einzelnen  Systemen? 

Um  eine  verniinftige  Bewertung  vorzunehmen,  werden  zunachst  Bewertungskriterien  be- 
notigt.  Bevor  diese  allerdings  genauer  diskutiert  werden,  sollte  man  sich  vor  Augen  fiihren 
was  man  hier  in  eine  Bewertung  setzen  will.  Es  soil  der  Versuch  gestartet  werden,  die  Syste¬ 
me  einander  abzuwagen.  Folgende  Kriterien,  die  ahnlich  des  vorangegangenen  Abschnitts 
von  der  Hardware-Sicht  zur  Application-Sicht  gestaffelt  sind,  gelten  als  Bewertungsgrund- 
lage: 

•  Kernel  GroBe 

•  Performance 

•  Portabilitat 

•  Skalierbarkeit 

8.5.1  Kernel 


Als  BewertungsmaBstab  in  Diskussionen  wird  sehr  gerne  der  Memory  Footprint,  also  der 
Speicheraufwand  eines  Betriebssystems,  herangezogen.  An  dieser  Stelle  hat  Microsoft  bei- 
spielsweise  die  Falschinformation  verbreitet,  dass  sich  bei  Linux  Embedded  Systemen  der 
Footprint  im  Bereich  von  mehreren  Megabyte  aufhalten  wiirde.  Dies  trifft  so  aber  nicht 
zu,  da  sich  beispielsweise  die  Produkte  der  Firma  LynuxWorks  (BlueCat,  LynxOS)  in  ei¬ 
nem  Bereich  von  ungefahr  250  KB  aufhalten.  Man  muss  sicherlich  auch  die  Aussagen  von 
LynuxWorks  in  diesem  Zusammenhang  kritisch  betrachten,  allerdings  gibt  es  wiederum 
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andere  Hersteller,  die  ihre  Betriebssysteme  ebenfalls  auf  Linux  stiitzen  und  auf  ihren  of- 
fiziellen  Internetprasenzen  ahnliche  Ergebnisse  verkiinden.  So  hat  zum  Beispiel  die  Firma 
Trolltech  das  System  Qt/EMBEDDED  in  ihrer  Produktpalette  und  dieses  begniigt  sich 
mit  rund  700  KB  in  der'Minimalkonfiguration.  Dahingehend  liegt  Symbian  OS  mit  den 
bereits  herangefiihrten  200  KB  gut  im  Vergleich.  Andere  Firmen  hingegen  schweigen  sich 
liber  ihre  Minimalkonfigurationen  aus. 


8.5.2  Portabilitat 

Die  Performance  kann  fiber  Benchmark-Tests  ermittelt  werden.  Das  ware  auf  der  einen 
Seite  eine  gute  Grundlage  zur  Bewertung  der  Systeme,  aber  auf  der  anderen  Seite  miiss- 
te  man  sich  dann  wiederum  auf  ein  bestimmtes  Zielsystem  festlegen.  Die  Performance 
ist  stark  abhangig  von  dem  Endprodukt  und  den  damit  verbundenen  Anforderungen,  so 
dass  man  vermutlich  in  jeder  Kombination  fur  das  eine  oder  andere  Betriebssystem  ar- 
gumentieren  konnte.  Fehlende  Features  sind  aber  wiederum  eine  gute  Ausgangslage  zur 
Bewertung.  In  diesem  Zusammenhang  sei  auf  die  Echtzeiteigenschaften  hingewiesen,  die 
jSymbian  nicht  aufweist  und  Microsoft  auch  nur  bedingt  leistet. 


8.5.3  Skalierbarkeit 

Die  Skalierbarkeit  bei  einem  Betriebssystem  wie  LynxOS  beziehungsweise  Windows  Mo¬ 
bile  2003  ist  aufgrund  der  Zielorientierung  gegeben.  Es  soil  an  dieser  Stelle  nicht  erneut 
auf  den  Vergleich  zwischen  den  beiden  Systemen  hingewiesen,  sondern  der  allgemeine  Um- 
stefnd  betont  werden,  dass  beispielsweise  ein  spezialisiertes  System  wie  Symbian  OS  hier 
nicht  in  Konkurrenz  stehen  kann. 


8.5.4  Performance 

Die  Performance  kann  fiber  Benchmark-Tests  ermittelt  werden.  Das  ware  auf  der  einen 
Seite  eine  gute  Grundlage  zur  Bewertung  der  Systeme,  aber  auf  der  anderen  Seite  miiss- 
te  man  sich  dann  wiederum  auf  ein  bestimmtes  Zielsystem  festlegen.  Die  Performance 
ist  stark  abhangig  von  dem  Endprodukt  und  den  damit  verbundenen  Anforderungen,  so 
dass  man  vermutlich  in  jeder  Kombination  fiir  das  eine  oder  andere  Betriebssystem  ar- 
gumentieren  konnte.  Fehlende  Features  sind  aber  wiederum  eine  gute  Ausgangslage  zur 
Bewertung.  In  diesem  Zusammenhang  sei  auf  die  Echtzeiteigenschaften  hingewiesen,  die 
Symbian  nicht  aufweist  und  Microsoft  auch  nur  bedingt  leistet. 


8.6  Fazit 


Es  konnten  an  dieser  Stelle  noch  viele  weitere  Kriterien  als  Bewertungsgrundlage  gelten,  al- 
lerdings  fallt  dann  die  Bewertung  zunehmend  schwerer.  Viele  Systeme  beschranken  sich  auf 
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einen  bestimmten  Bereich  und  wollen  nicht  in  Konkurrenz  mit  anderen  Betriebssystemen 
stehen.  Weitere  Kriterien  konnten  aber  beispielsweise  Verwendete  Bausteine,  Unterstiitzte 
Features,  Benutzerfreundlichkeit  (in  dem  Zusammenhang  eher  Enwicklerfreundlichkeit), 
u.v.m.  sein.  Man  kann  erkennen,  dass  entweder  die  Grundlage  oder  die  Ausrichtung  selbst 
nicht  immer  gleich  ist.  Daher  fallt  auch  ein  abschliefiendes  Urteil  schwer.  Es  soli  an  die- 
ser  Stelle  darauf  verzichtet  werden  ein  Praferenz  zum  Ausdruck  zu  bringen.  Vor-  und 
Nachteile  wurden  hier  diskutiert  und  es  sollte  hervorgegangen  sein,  dass  die  beabsichtigte 
Anwendung  Prioritat  bei  der  Auswahl  eines  solchen  Betriebssystems  hat.  Der  Ausblick 
am  Ende  dieser  Ausarbeitung  gibt  in  diesem  Zusammenhang  eine  klarere  Aufstellung  und 
Abgrenzung  fur  die  Zukunftsaussichten  in  diesem  Bereich. 

8.7  Java  2  Micro  Edition  (J2ME)  -  Java  Umgebung 
fur  Embedded  Anwendungen 

J2ME  ist  eine  Teilmenge  von  J2SE,  die  das  Minimum  an  Unterstiitzung  beinhaltet,  das  fur 
mobile  Endgerate  benotigt  wird.  Die  Aussage  der  Teilmenge  muss  gleich  noch  relativiert 
werden,  aber  fur  den  Moment  nehmen  wir  dies  so  an.  Da  es  im  Bereich  der  Kleingerate  eine 
so  breite  Palette  an  verschiedenen  Hardwarevoraussetzungen  gibt,  entschied  sich  SUN  fur 
die  Moglichkeit  der  gerategruppenspezifischen  Erweiterung  der  Spezifikation.  Dies  klingt 
erst  einmal  sehr  kompliziert,  bedeutet  aber  nichts  anderes,  als  dass  ein  Teil  der  J2ME 
fur  alle  Gerate  festgelegt  ist,  wobei  ein  anderer  Teil  fur  eine  entsprechende  Gerategruppe 
spezifisch  ausgelegt  ist.  Diese  spezifischen  Auslegungen  nennt  man  Konfigurationen  und 
Profile.  [2] 


8.7.1  Einordnung  und  Zielsetzung  von  MIDP 

Sun  hat  bei  der  Entwicklung  von  Java  2  eine  Aufteilung  in  drei  Teile  (J2EE,  J2SE,  J2ME) 
vorgenommen.  Welcher  Teil  jeweils  benutzt  wird,  hangt  im  wesentlichen  vom  Einsatzge- 
biet,  der  zu  erstellenden  Applikation  ab.  Wir  beschaftigen  uns  mit  dem  Einsatz  von  Java 
in  Handys,  Pagers  und  Smartphones.  Die  sogenannte  Konfiguration,  die  in  diesem  Ge- 
biet  eingesetzt  wird,  tragt  den  Namen  CLDC  (Connected  Limited  Device  Configuration). 
Da  das  API,  das  mit  dieser  Konfiguration  ausgeliefert  wird,  dem  Entwickler  nur  eini- 
ge  Grundfunktionalitaten  zur  Verfiigung  stellt,  bedarf  es  einer  Erweiterung  dieses  API’s 
mittels  eines  zusatzlichen  Profils.  Das  Profil  wird  in  diesem  Einsatzgebiete  mit  “Mobile 
Information  Device  Profile"  (MIDP)  bezeichnet. 


8.7.2  Architektur 

In  diesem  Abschnitt  geht  es  um  den  architektonischen  Aufbau  der  Software,  auf  wel¬ 
cher  MID- Applikation  resp.  MIDlets  ausgefiihrt  werden  konnen  (siehe  Abbildung  6).  Auf 
der  jeweiligen  Hardware  eines  “Mobile  Information  Device"  (MID)  lauft  ein  relativ  kleines 
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Betriebssystem,  das  die  wichtigsten  Hardware-Eigenschaften  kapselt.  Auf  diesem  Betriebs- 
system  setzt  die  KVM  (K  Virtual  Machine)  auf.  Die  KVM  iibernimmt,  wie  wir  es  von 
einer  Virtual  Machine  gewohnt  sind,  das  Abbilden  von  Java-Bytecode-Instruktionen  auf 
das  Betriebssystem. 


MIDP  Profile  Applications 


OEM  Applications 
OEM  Specific  APIs 


MIDP 


CLDC/KVM 


Operating  System 


Abbildung  8.7:  Position  des  Mobile  Information  Device  Profiles  (MIDP)  innerhalb  des 
Runtime  Enivirnonment 

Unmittelbar  auf  der  KVM  setzt  das  CLDC-API  auf,  welches  seinerseits  Dienste  fiir 
das  MIDP-API  zur  Verfiigung  stellt.  Das  MIDP-API  bietet  dem  Entwickler  eine  Rei- 
he  von  Funktionen  an,  die  in  der  gleichnamigen  Spezifikation  definiert  sind.  Eine  MID- 
Applikation,  die  ihrerseits  auf  dem  CLDC-API  resp.  MIDP-API  aufsetzt,  sollte  “theo- 
retisch"  plattform-unabhangig  sein.  Neben  dem  MIDP-API  ist  es  dem  Entwickler  selber 
iiberlassen  weitere  Funktionen  zu  implementieren,  welche  moglicherweise  auf  ein  spezifi- 
sches  Gerat  zugeschnitten  sind  (in  Abbildung  2  als  “OEM-Specific- API“  bezeichnet).  Die. 
Applikationen,  die  von  solchen  Funktionen  Gebrauch  machen  oder  moglicherweise  direkt 
auf  Betriebssystemfunktionen  zugreifen,  reizen  vielleicht  die  spezifischen  Dienste  eines 
Gerates  besser  aus,  verlieren  aber  mit  Sicherheit  die  Plattformunabhangigkeit. 


8.7.3  Voraussetzungen 

Die  Variation  an  Betriebssystemen  in  MID-Geraten  ist  relativ  grofi.  Einige  Betriebssys- 
teme  bieten  ein  ausgereiftes  Dateisystem  an  und  andere  stellen  nichts  derartiges  zur  Ver- 
fiigung.  Aufgrund  der  grofien  Unterschiede  setzt  die  MIDP-Spezifikation  die  folgenden 
Voraussetzungen  an  das  Betriebsystem  eines  MID  voraus: 

•  Kernel 

Es  wird  nur  ein  kleiner  Kernel  verwendet,  zur  Hardwaresteuerung,  Interruptbehand- 
lung,  fiir  Exceptions  und  minimales  Scheduling. 

•  Storage 

MIDP  bietet  fiir  MIDlets  die  Moglichkeit  Daten  zu  speichern  und  diese  spater  wieder 
zu  verwenden.  Der  persistente  Speicher  wird  als  Record  Management  System  (RMS) 
bezeichnet  und  ist  einfach  als  Datenbank  realisiert.  Die  Daten  werden  als  Records 
abgelegt. 
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•  Networking 

Networking  ist  mit  Hilfe  einer  Teilmenge  des  http-Protokolls  realisiert.  Es  konnen 
sowohl  IP-Protokolle  als  auch  WAP  oder  i-mode  genutzt  werden. 

•  Timers 

CLDC  bietet  keine  Timerfunktion.  MID  fiihrt  java.util. Timer  und  java.util.Timertask 
ein.  Damit  konnen  MIDlets  Timer  nutzen.  Applicationen  konnen  so  Aktionen  verzo- 
gern  oder  spater  ausfiihren.  '  ' 

•  Display 

Bildschirmgrofie:  96  x  54,  Farbtiefe 

8.8  Ausblick 

Der  Markt  fiir  Betriebssysteme  fur  mobile  Systeme  ist  aufierst  umfangreich.  Es  gibt  Un- 
mengen  an  Systemen  und  Derivaten.  Aber  nach  dem  fiinften  Linux-Klon  kommen  nur 
noch  wenig  neue  Aspekte  hinzu.  Im  Rahmen  einer  Seminararbeit  war  es  leider  nicht  mog- 
lich  auf  alle  einzugehen  und  samtliche  Systeme  vorzustellen.  Auch  wenn  dieses  Streben 
moglicherweise  schon  im  Vornherein  dank  der  Grofie  dieses  Marktes  zum  Scheitern  ver- 
urteilt  sein  konnte,  so  ware  es  sicherlich  im  allgemeinen  Interesse  gewesen  auf  weitere 
Betriebssysteme,  wie  z.B.  Palm  OS  einzugehen.  Ein  weiterer  Aspekt  ist  der  der  Fache- 
rung.  Mobile  Endsysteme  gehen  teilweise  in  ganz  unterschiedliche  Richtungen  und  sind 
nur  auf  unterster  Ebene  miteinander  vergleichbar. 

Es  mag  mobile  Systeme  geben,  die  nicht  eingebettet  sind  (moderne  PDAs,  die  Zugriff 
auf  das  OS  zulassen);  es  gibt  auch  embedded  Systems,  die  nicht  mobil  sind.  Das  andert 
an  den  Anforderungen  oder  dem  grundlegenden  Aufbau  dieser  Systeme  kaum  etwas.  Die 
Anforderungen  sind  klar  und  der  Aufbau  wurde  erlautert.  Wichtig  ist  das  Einsatzgebiet. 
Wie  schon  erwahnt,  ist  der  Markt  fiir  mobile  Endsysteme  sehr  umfangreich  und  grofi. 
Allein  der  Anteil  der  embedded  systems  ist  enorm.  Und  auch  die  Entwicklungen  schreiten 
stetig  voran,  so  dass  ein  Ausblick  nur  unter  den  aktuellen  Begebenheiten  giiltig  sein  kann 
und  damit  wahrscheinlich  schon  in  naher  Zukunft  iiberholt  sein  konnte.  Man  setzt  zuneh- 
mend  auf  iibergreifende  Dienstleistungen,  die  dem  Benutzer  das  Leben  vereinfachen  sollen, 
Und  diese  Entwicklung  passiert  nicht  nur  in  diesem  Marktsegment,  sondern  durchdringt 
alle  Hersteller  von  mobilen  Endprodukten.  Multi-Funktionalitat  wird  durch  einen  zuneh- 
menden  Satz  an  Anwendungssoftware  gefordert  (vgl.  SmartPhones,  Handy  mit  Kamera, 
etc.).  Abseits  dieser  Entwicklung  herrscht  immer  noch  ein  harter  (ggf.  auch  ideologischer) 
Konkurrenzkampf  zwischen  Windows  und  Linux  Anhangern  statt.  Wer  sich  hier  behaup- 
ten  kann,  ware  zu  diesem  Zeitpunkt  kaum  abzuwagen.  Es  gibt  aktuell  zu  viele  Argumente 
fiir  und  wider  einem  bestimmten  Betriebssystem,  so  dass  man  hochstens  die  Vermutung 
aufkeimen  lassen  konnte,  dass  die  Firmen  mit  dem  “langerem  Atem“  das  Rennen  machen. 
So  gibt  es  zwar  eine  hohe  Bandbreite  an  Systemen,  aber  im  Falle  Microsoft  hat  die  Firma 
eindeutig  hohere  Mittel,  um  ihre  Produkte  auf  dem  Markt  zu  forcieren.  Symbian  OS  hat 
derweil  ihre  7.x  Reihe  herausgebracht.  Ebenso  Einfluss,  MarktgroBe  und  Erfahrung  kon¬ 
nen  nur  bedingt  als  Erfolgsgarant  fiir  die  Zukunft  gelten.  Fakt  ist  allerdings,  dass  dieser 
Markt  einen  hohen  Einfluss  auf  das  alltagliche  Leben  hat  und  immer  mehr  Zuwachs  erhalt. 
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